Numeric Revision Names?

Hi,

I am new to git, and my question may be stupid, but anyway... I am used to the numeric revision names on svn, and on Git all I get are hexadecimal names.

Is there any way to configure it to start a projects revisions on lets say, revision 0, and keep incrementing it after each commit?

I tried finding it on git doc but wasnt able to. Maybe I am missing something....

Thanks in advance!

This can be emulated to some extent by using git tag, and git describe --tags. I can't remember specifics off the top of my head though, it's a while since I set that up.

On Fri, Oct 3, 2008 at 1:37 PM, marceloribeiro <marcelo@sonnay.com> wrote:

marceloribeiro <marcelo@sonnay.com> writes:

[...]

No.

[...]

(There's no such numbering system that would work entirely satisfactorily in a distributed system. Some systems have numbering schemes that are perhaps easier to use (at least for some purposes) than the underlying hashes, but no such scheme is used in git.)

marceloribeiro <marcelo@sonnay.com> writes:

First, it is simply not possible to have incremental revision numbers in distributed version control system like Git, at least not without some central authority (assigning revision numbers). Other distributed SCM use simple revision numbers, but either they are local to branch and local to repository (not shared) as in case of Mercurial, or require centralized workflow where one uses different merge than in leaf repositories, as from what I understand is the case with dotted revision numbers in Bazaar-NG.

Second, in my opinion revision numbers are not that useful for projects with large number of commits (where revision number might be something like r4321), and nonlinear history (you don't know how r4555 relates to r4556: they might be on different branches). Also you don't have to use full revision numbers: you can use shortened revision numbers (usually 6-8 characters is enough, e.g. 5f2d4160); if you use tags to mark released versions you can use git-describe output to count revisions from given tag (output contains sha-1 because history migh branch after tag, and number of commits since tag is not enough to determine commit/revision; e.g. v1.6.0-rc3-17-gc14c8ce which means 17 commits after tag v1.6.0-rc3).

Additionally when using git you usually use transient revision numbers, counting commits from tip of branch, for example master~5 means 5 commits in first-parent line from what branch 'master' points to now.

For projects that do have a central authority (e.g. internal corporate projects), revision numbers make more sense.

Granted, they are on separate branches (like svn), but the nice thing about them is that they are monotonically increasing. E.g. our qa people love numbers--the bug fix ticket says dev just put in r100...qa/production box says it is on r95. Doesn't matter the branch/whatever, they know the box doesn't have r100. Now, right, if its r105, it is trickier, although we also throw in branch name (e.g. topica-r100) which means no false positives but can lead to false negatives.

Per Robin's response and then a thread on the list a year+ ago, a hook+tags can be used to fake this, and we're doing that now. I've been meaning to put our hooks repo up somewhere, as we've got several fun hooks that are focused on an internal/centralized workflow, but I haven't gotten to it yet. For now I've just attached the commit numbers script.

For our team, lack of monotonic version numbers was a big deal--as in can't use git sort of big deal. I wouldn't be surprised if it is a contributing factor that keeps other people, especially internal teams, from git. I understand all of the reasons it can't be in git proper, but an FAQ entry about the hook/tag hack or link to a contrib script might be useful (not necessarily the one attached, given its functions/etc. baggage).

- Stephen

Stephen Haberman wrote:

I wonder how that constitutes an argument for revision numbers.

First, the _only_ guarantee you get out of monotonically increasing revision numbers is that they're ... monotonically increasing. You might as well use the commit (not author!) timestamp for that purpose (assuming your clocks are all synced). They do not convey history membership, only history non-membership, for the same obvious reason that commit timestamps do.

Second, Git can do the check you mention above much more accurately. If you tell QA that the fix is in 123abc, then 'git branch --contains 123abc' lists all local branches that have the fix, 'git describe --contains 123abc' gives you the nearest tag (i.e. usually the lowest-numbered release version number) having the fix, etc.

True. Revision numbers are typically shorter though. E.g. we're on ~19,000 now, which is less digits than 20081003122101.

I know--see my explicit disclaimer about false negatives in my previous post.

I'll nit pick, revision numbers if put together with branch name, can actually occassionally convey history membership (subject to false negatives).

For example, our bug fix hook will say "hashX committed on topica as r100" and so if qa is looking at a build that was built while on topica at r105 (so labeled) "topica-r105") then it is very likely hashX is on the box.

Okay, not with branch renames, but for all intents and purposes. Of course, as you point out, topicb-r106 says nothing about the availability of hashX, but that is a less common question for our qa team than the first two. And they ask the question often enough during the day that addressing the major 2 of the 3 cases helps cut down "hey dev--I've got this hash..." calls.

Do not confuse my willingness to hack commit numbers into our git repo (and my willingness to share our hack with the original poster) with full fledged support of the concept. Hashes are superior, but, when they work, revision numbers are nice too. I did not see a reason we could not have both, especially if it made people more comfortable with git.

(I also face/faced a situation where "monotonic revision numbers" were essentially a check box item on a required list of SCM features, so despite whatever I/the-git-team/etc. thought about their technical inferiority, it was a criteria that could have ruled git out for us. Hence my mentioning an FAQ entry for others faced with my same political situation.)

- Stephen

Surely!

Yes

It would be good to have this feature in git.

Yes, it's true that this is a big deal for many people out there.

That would be helpful, if it cannot go in git proper for real in the centralized model.

This is so true in a corporate environment with centralized repositories, then I completely agree that in the case git is being used in this model (many companies are really used to that), the monotonic revision number is helpful and sometimes is showstopper to not have them.

Regards,

2008/10/5 André Goddard Rosa <andre.goddard@gmail.com>:

But you do have them, even now. With that simple hook script.

And outside of your small corporation noone needs them (and your company doesn't need them either, they just can't get over the mindset of rcs or vms native versioning or whatever else they're plainly used to).

On Fri, Oct 03, 2008 at 11:55:57AM -0500, Stephen Haberman wrote:

If you are constraining yourself to a central repo, then you could just add a receive hook that tags each new commit with a monotonically increasing revision number. Clients would get the tags upon fetch.

Something like the following (totally untested, and probably needs to handle locking and errors more sanely) in the post-receive hook:

  n=`cat revnumber 2>/dev/null || echo 0`
  while read old new branch; do
    git rev-list $old..$new |
      while read rev; do
        n=$(($n+1))
        git tag r$n $rev
      done
  done
  echo $n >revnumber

-Peff

On Fri, Oct 03, 2008 at 01:14:34PM -0400, Jeff King wrote:

Oh, nevermind. I'm an idiot and didn't bother reading to the end of your post, where you clearly attached a hook that does exactly that.

Sorry for the noise.

-Peff