Wireshark-dev: Re: [Wireshark-dev] GIT tutorials
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Gerald Combs <gerald@xxxxxxxxxxxxx>
Date: Tue, 11 Mar 2014 15:42:13 -0700
On 3/11/14 3:32 PM, Hadriel Kaplan wrote:
> 
> On Mar 11, 2014, at 5:38 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
> 
>> On Tue, Mar 11, 2014 at 5:34 PM, Hadriel Kaplan
>> <hadriel.kaplan@xxxxxxxxxx> 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.

Would `git describe` suit your needs?

$ git describe
v1.11.3-rc1-1917-gd3b8084

The current tag is v1.11.3-rc1. There are 1917 commits between
v1.11.3-rc1 and gd3b8084.

$ git describe --match v1.11.0-rc1
v1.11.0-rc1-5874-gd3b8084

There have been 5874 commits since v1.11.0-rc1 was tagged.