Home page logo

wireshark logo Wireshark mailing list archives

Re: GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
From: Graham Bloice <graham.bloice () trihedral com>
Date: Tue, 11 Mar 2014 21:11:49 +0000

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>
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
!= 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
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
build from a clone from the main repo, or use an automated build, thus
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.
could say to users that an issue was fixed in svn r nnnn and they
"know" that any rev later than that was good.  I don't understand how
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
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.

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]