On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice <graham.blo...@trihedral.com> wrote: > On 11 March 2014 20:35, Evan Huus <eapa...@gmail.com> wrote: >> >> On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall <rkn...@gmail.com> 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. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
