Wireshark · Wireshark-dev: Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)

[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

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).