Numeric Revision Names?

Numeric Revision Names?

[marceloribeiro]

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.

Re: Numeric Revision Names?

[Robin Burchell]

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

Re: Numeric Revision Names?

[Bruce Stephens]

marceloribeiro <marcelo@sonnay.com> writes:

[...]

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

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

Re: Numeric Revision Names?

[Jakub Narebski]

marceloribeiro <marcelo@sonnay.com> 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

Re: Numeric Revision Names?

[Stephen Haberman]

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]


> 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


[-- Attachment #2: functions --]
[-- Type: application/octet-stream, Size: 6725 bytes --]

#!/bin/sh

# Sets: new_commits
# Assumes: $oldrev $newrev $refname
#
# This is for use in post receive hooks, as it assumes the refname has moved and
# is now newrev, we need to discard it. This is down with bash string replace,
# as it will replace only the first match, compared to the canonical "grep -v"
# approach which will throw out multiple matches if the same commit is referred
# to by multiple branches.
#
# Excellent, excellent docs from Andy Parkin's email script
#
##################################################
#
# Consider this:
#   1 --- 2 --- O --- X --- 3 --- 4 --- N
#
# O is $oldrev for $refname
# N is $newrev for $refname
# X is a revision pointed to by some other ref, for which we may
#   assume that an email has already been generated.
# In this case we want to issue an email containing only revisions
# 3, 4, and N.  Given (almost) by
#
#  git rev-list N ^O --not --all
#
# The reason for the "almost", is that the "--not --all" will take
# precedence over the "N", and effectively will translate to
#
#  git rev-list N ^O ^X ^N
#
# So, we need to build up the list more carefully.  git rev-parse
# will generate a list of revs that may be fed into git rev-list.
# We can get it to make the "--not --all" part and then filter out
# the "^N" with:
#
#  git rev-parse --not --all | grep -v N
#
# Then, using the --stdin switch to git rev-list we have effectively
# manufactured
#
#  git rev-list N ^O ^X
#
# This leaves a problem when someone else updates the repository
# while this script is running.  Their new value of the ref we're
# working on would be included in the "--not --all" output; and as
# our $newrev would be an ancestor of that commit, it would exclude
# all of our commits.  What we really want is to exclude the current
# value of $refname from the --not list, rather than N itself.  So:
#
#  git rev-parse --not --all | grep -v $(git rev-parse $refname)
#
# Get's us to something pretty safe (apart from the small time
# between refname being read, and git rev-parse running - for that,
# I give up)
#
#
# Next problem, consider this:
#   * --- B --- * --- O ($oldrev)
#          \
#           * --- X --- * --- N ($newrev)
#
# That is to say, there is no guarantee that oldrev is a strict
# subset of newrev (it would have required a --force, but that's
# allowed).  So, we can't simply say rev-list $oldrev..$newrev.
# Instead we find the common base of the two revs and list from
# there.
#
# As above, we need to take into account the presence of X; if
# another branch is already in the repository and points at some of
# the revisions that we are about to output - we don't want them.
# The solution is as before: git rev-parse output filtered.
#
# Finally, tags: 1 --- 2 --- O --- T --- 3 --- 4 --- N
#
# Tags pushed into the repository generate nice shortlog emails that
# summarise the commits between them and the previous tag.  However,
# those emails don't include the full commit messages that we output
# for a branch update.  Therefore we still want to output revisions
# that have been output on a tag email.
#
# Luckily, git rev-parse includes just the tool.  Instead of using
# "--all" we use "--branches"; this has the added benefit that
# "remotes/" will be ignored as well.
#
##################################################
function set_new_commits() {
	nl=$'\n'

	# Get all the current branches, not'd as we want only new ones
	new_commits=$(git rev-parse --not --branches)

	# Strip off the not current branch
	new_hash=$(git rev-parse $refname)
	new_commits=${new_commits/^$new_hash/}

	# Put back newrev without the not
	new_commits=${new_commits}${nl}${newrev}

	# Put in ^oldrev if it's not a new branch
	if [ "$oldrev" != "0000000000000000000000000000000000000000" ] ; then
		new_commits=${new_commits}${nl}^${oldrev}
	fi

	new_commits=${new_commits/$nl$nl/$nl}
	new_commits=${new_commits/#$nl/}
}

# Sets: $change_type
# Assumes: $oldrev $newrev
#
# --- Interpret
# 0000->1234 (create)
# 1234->2345 (update)
# 2345->0000 (delete)
function set_change_type() {
	if [ "$oldrev" == "0000000000000000000000000000000000000000" ] ; then
		change_type="create"
	else
		if [ "$newrev" == "0000000000000000000000000000000000000000" ] ; then
			change_type="delete"
		else
			change_type="update"
		fi
	fi
}

# Sets: $newrev_type $oldrev_type $rev $rev_type
# Assumes: $newrev $oldrev
# --- Get the revision types
function set_rev_types() {
	newrev_type=$(git cat-file -t "$newrev" 2> /dev/null)
	oldrev_type=$(git cat-file -t "$oldrev" 2> /dev/null)
	if [ "$newrev" == "0000000000000000000000000000000000000000" ] ; then
		rev_type="$oldrev_type"
		rev="$oldrev"
	else
		rev_type="$newrev_type"
		rev="$newrev"
	fi
}

# Sets: $describe
# Assumes: $rev
#
# The email subject will contain the best description of the ref that we can build from the parameters
function set_describe() {
	rev_to_describe="$rev"
	if [ "$1" != "" ] ; then
		rev_to_describe="$1"
	fi

	describe=$(git describe $rev_to_describe 2>/dev/null)
	if [ -z "$describe" ]; then
		describe=$rev_to_describe
	fi
}

# Sets: $describe_tags
# Assumes: $rev
#
# The email subject will contain the best description of the ref that we can build from the parameters
function set_describe_tags() {
	rev_to_describe="$rev"
	if [ "$1" != "" ] ; then
		rev_to_describe="$1"
	fi

	describe_tags=$(git describe --tags $rev_to_describe 2>/dev/null)
	if [ -z "$describe_tags" ]; then
		describe_tags=$rev_to_describe
	fi
}

# Takes a lockfile path and command to execute once the lock is acquired.
#
# Retries every second for 5 minutes.
#
# with_lock "foo.lock" "echo a"             # Works
# with_lock "foo.lock" "echo b1 ; echo b2"  # Work
# function several() {
# echo several1 ; echo several2
# }
# with_lock "foo.lock" several              # Works
#
function with_lock() {
	lockfile="$1"
	block="$2"
	with_lock_has_lock=1

	trap with_lock_unlock_if_held INT TERM EXIT
	lockfile -1 -r 300 "$lockfile"
	with_lock_has_lock=$?
	if [ $with_lock_has_lock -ne 0 ] ; then
		exit $?
	fi
	eval "$block"
	rm -f "$lockfile"
	with_lock_has_lock=1
}

function with_lock_unlock_if_held() {
	if [[ "$with_lock_has_lock" -eq 0 ]] ; then
		rm -f "$lockfile"
	fi
}

function display_error_message() {
	echo "----------------------------------------------------" >&2
	echo ""                                                     >&2
	echo ""                                                     >&2
	for ((i=1;i<=$#;i+=1)); do
	eval message="$"$i
	echo "$message"                                             >&2
	done
	echo ""                                                     >&2
	echo ""                                                     >&2
	echo "----------------------------------------------------" >&2
}


[-- Attachment #3: post-receive-assign-commit-numbers --]
[-- Type: application/octet-stream, Size: 502 bytes --]

#!/bin/sh

. $(dirname $0)/functions

while read oldrev newrev refname ; do
	set_new_commits
	echo "$new_commits" | git rev-list --reverse --stdin | while read commit ; do
		if [[ $(grep "$commit" "$GIT_DIR/commitnumbers" 2>/dev/null) == "" ]] ; then
			with_lock "$GIT_DIR/commitnumbers.lock" 'echo "$commit $refname" >> "$GIT_DIR/commitnumbers"'
			number=$(grep --max-count=1 --line-number "$commit" "$GIT_DIR/commitnumbers" | grep -oP "^\d+(?=:)")
			git tag "r/$number" "$commit"
		fi
	done
done

Re: Numeric Revision Names?

[Thomas Rast]

[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]

Stephen Haberman wrote:
> 
> > 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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Numeric Revision Names?

[Jeff King]

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

Re: Numeric Revision Names?

[Jeff King]

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

Re: Numeric Revision Names?

[Stephen Haberman]

> 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

Re: Numeric Revision Names?

[André Goddard Rosa]

> 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

Re: Numeric Revision Names?

[Alex Riesen]

2008/10/5 André Goddard Rosa <andre.goddard@gmail.com>:
> 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).