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!
-- 
View this message in context: http://www.nabble.com/Numeric-Revision-Names--tp19796862p19796862.html
Sent from the git mailing list archive at Nabble.com.

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 [off-list ref] wrote:

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!
--
View this message in context: http://www.nabble.com/Numeric-Revision-Names--tp19796862p19796862.html
Sent from the git mailing list archive at Nabble.com.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

marceloribeiro [off-list ref] writes:

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....

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.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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).

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:

quoted

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).

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.

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.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

On Fri, Oct 03, 2008 at 01:14:34PM -0400, Jeff King 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.

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

You might as well use the commit (not author!) timestamp for that
purpose (assuming your clocks are all synced).

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

They do not convey history membership, only history non-membership,
for the same obvious reason that commit timestamps do.

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

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

Surely!

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.

Yes

haven't gotten to it yet. For now I've just attached the commit
numbers script.

It would be good to have this feature in git.

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

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

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).

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

(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.)

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,
-- 
[]s,
André Goddard

2008/10/5 André Goddard Rosa [off-list ref]:

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.

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:

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.

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