On Tue, Mar 11, 2014 at 5:11 PM, Graham Bloice
<graham.bloice@xxxxxxxxxxxxx> wrote:
> On 11 March 2014 21:06, Evan Huus <eapache@xxxxxxxxx> wrote:
>>
>> On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice
>> <graham.bloice@xxxxxxxxxxxxx> wrote:
>> > On 11 March 2014 20:50, Evan Huus <eapache@xxxxxxxxx> wrote:
>> >>
>> >> On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice
>> >> <graham.bloice@xxxxxxxxxxxxx> wrote:
>> >> > On 11 March 2014 20:35, Evan Huus <eapache@xxxxxxxxx> wrote:
>> >> >>
>> >> >> On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall <rknall@xxxxxxxxx>
>> >> >> wrote:
>> >> >> > Git commit ids differ
>> >> >> > between different people (each clone may create their one)
>> >> >>
>> >> >> Not technically true. If I make a commit with SHA x, push it, and it
>> >> >> gets submitted, then it is true that the final SHA in master will be
>> >> >> y
>> >> >> != x. However, the next time I pull then I will get SHA y as well.
>> >> >> They x and y technically reference different commits, since y
>> >> >> contains
>> >> >> additional information about who reviewed it, when it was submitted
>> >> >> from Gerrit, etc.
>> >> >>
>> >> >
>> >> > But aren't we talking about users, rather than devs? Users will
>> >> > either
>> >> > build from a clone from the main repo, or use an automated build,
>> >> > thus
>> >> > their
>> >> > reference point will be the Gerrit | master SHA whichever is the most
>> >> > appropriate name for it.
>> >> >
>> >> > In any case I don't think this fulfils the initial question.
>> >> > Previously
>> >> > we
>> >> > could say to users that an issue was fixed in svn r nnnn and they
>> >> > would
>> >> > "know" that any rev later than that was good. I don't understand how
>> >> > they
>> >> > can "know" that with a SHA of the latest master commit | merge.
>> >>
>> >> SHAs aren't ordered like SVN revisions are (so given two arbitrary
>> >> SHAs and nothing else I can't determine which came first) but they do
>> >> still have an ordering in the repository.
>> >>
>> >> Regardless, we can say: fixed in commit SHA. They can pull, and if
>> >> "git show SHA" shows the revision then they've got it. Otherwise they
>> >> don't.
>> >>
>> >
>> > That doesn't help "users" who only install, not build as their copy of
>> > Wireshark doesn't have a list of SHA (or does it?).
>> >
>> > They only way I can think of resolving that is to refer to dates as they
>> > are
>> > time-ordered (I hope).
>>
>> Time still works; if it was submitted to master at noon on Monday then
>> presumably any automated build from after that point will include the
>> relevant change.
>>
>> Alternatively, the automated build files have the name format:
>> Wireshark-$Platform-$Tag-$CommitsSinceTag-g$SHA.exe (e.g.
>> Wireshark-win32-1.11.3-1925-g0f73f79.exe)
>>
>> So if you know the change was in SHA x (and the current latest tag is
>> y), you can run "git rev-list y..x --count" and it will give you the
>> $CommitsSinceTag value which is strictly increasing like an SVN
>> revision number.
>>
>
> I think you're still missing the point. Users who install don't have git,
> all they have is the "About" box. The information there "should" be enough
> to allow them to locate a bug on Bugzilla and determine if their version has
> been "fixed".
It's not. But if they ask, it's relatively easy for somebody with git
to be able to find out.