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.