Re: GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)

[Graham Bloice <graham.bloice () trihedral com>]

On 11 March 2014 21:06, Evan Huus <eapache () gmail com> wrote:

> On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice
> <graham.bloice () trihedral com> wrote:
> > On 11 March 2014 20:50, Evan Huus <eapache () gmail com> wrote:
> > > On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice
> > > <graham.bloice () trihedral com> wrote:
> > > > On 11 March 2014 20:35, Evan Huus <eapache () gmail com> wrote:
> > > > > On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall <rknall () 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".

___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe