On Tue, Mar 11, 2014 at 5:11 PM, Graham Bloice <graham.blo...@trihedral.com> wrote: > On 11 March 2014 21:06, Evan Huus <eapa...@gmail.com> wrote: >> >> On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice >> <graham.blo...@trihedral.com> wrote: >> > On 11 March 2014 20:50, Evan Huus <eapa...@gmail.com> wrote: >> >> >> >> 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. >> >> >> > >> > 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. ___________________________________________________________________________ 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
