Re: Creating something like increasing revision numbers

On Mon, Oct 19, 2009 at 02:44:47AM +0200, Norbert Preining wrote:

Hi all,

thanks everyone for the nice feedback!

On So, 18 Okt 2009, Daniel Barkalow wrote:

quoted

It's possible as long as you don't think of the "version number" as a 
property of the commit, but rather a property that some commits get by 
virtue of having been at some time the commit that's what would be found 
on that particular server at that particular time. Even though the history 

Right! That is a good point. In fact I don't care about (local) commits,
but about the pushes to the central server.

quoted

of the *content* is non-linear, the sequence of values stored in 
refs/heads/master on your central server is linear, local, and easy to 
enumerate.

That is exactely what I need.

If you have any control over how people will use git,
then you can give your constantly-incrementing revision number
more stability by ensuring that everyone uses
'git pull --rebase'.

That'll literally keep the history completely linear.
If someone forgets then it's not a big deal; you'll
just get a merge commit and the number will increment
by 2 instead of by 1.

Now my follow-up questions:
- how would one access this "sequence" number on the server

If you've done the "tag the initial commit" as suggested
elsewhere on this thread:

	git tag projectname $(git rev-list HEAD | tail -n1)

then you can do this with simply:

	git describe --tags


It should output something like:

	projectname-101-g20912df

- is there a way to determine at which of this "sequence" numbers a specific
  file has been changed last?

	commit=$(git log --pretty=%H -1 -- <filename>)
	git describe --tags $commit

JAIST Japan Advanced Institute of Science and Technology   preining@jaist.ac.jp
Vienna University of Technology                               preining@logic.at
Debian Developer (Debian TeX Task Force)                    preining@debian.org

Just another happy Debian user here,

-- 
		David