Wireshark-dev: Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems wi
From: Hadriel Kaplan <[email protected]>
Date: Tue, 11 Mar 2014 18:32:45 -0400
On Mar 11, 2014, at 5:38 PM, Evan Huus <[email protected]> wrote:

> On Tue, Mar 11, 2014 at 5:34 PM, Hadriel Kaplan
> <[email protected]> wrote:
>> Googling around a bit for this issue - because other apps must have this same problem and their users - shows people either creating a ton of tags, or scripting with the rev-list count to generate sequential numbers in their commits to master.
>> How did SVN deal with a rev number in older branches, when you either backported a change from a newer release or committed a change only to the older release?  Did it use the same rev number, or give it a new one? (ie, was it the same/shared numberspace?)
> It gave it a new one (just like backported git revs get new SHAs) but
> that's not really the problem. The problem is that the user only knows
> their build was at some particular SHA; they don't know whether the
> SHA they're interested in came before or after it.

No, but I was already jumping ahead to a possible (crazy) solution. :)

Since SVN used a single number space but gave each branch's commits new numbers, you can create a new "revision" string that looks like "<tag>:<number>", where <tag> is the branch tag and <number> is the rev-list count of origin HEAD for each branch.  The <tag> keeps them unique per branch, and also quickly tells the user which release branch that change is in.

Is there a way to have a hook script that only takes effect when committing into the master branches? (ie, only when you guys cherry-pick and commit a change to the real master/master-x.x repositories?)  If so, you could create a script which gets invoked during the cherry-pick commit into master/master-x.x, which inserts this "<tag>:<number>" string into the commit message.[1] For example adds a "Revision: 1.11:12345" to the end of the commit message, similar to the commit-msg Change-ID line.

That way backporting also appends additional revision info lines to the commit message, and each one is unique/identifiable by the <tag> portion.

Copy that "<tag>:<number>" into the cherry-pick message you guys post on gerrit reviews (or is that scripted too?).  And lastly, when the buildbots build a new nightly or tagged release, have them use the rev-list count for the given branch being built, for the binary file name and about-page info in the build.

[1] making it an atomic operation might be tricky though - dunno anything about how git does that. Might want to have the <number> be stored in a git-controlled file, in each repository?