Wireshark-dev: Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems wi
From: Graham Bloice <[email protected]>
Date: Tue, 11 Mar 2014 20:58:19 +0000
On 11 March 2014 20:50, Evan Huus <[email protected]> wrote:
On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice
<[email protected]> wrote:
> On 11 March 2014 20:35, Evan Huus <[email protected]> wrote:
>> On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall <[email protected]> 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

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