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.
