Re: Subversion-style incrementing revision numbers

[Jakub Narebski <jnareb@gmail.com>]

Jakub Narebski wrote:

> Joel Dice wrote:
> 
>> I'm considering adopting Git for a medium-sized project which is currently 
>> managed using Subversion.  I've used Git for a few smaller projects 
>> already, and the thing I've missed most from Subversion is the convenience 
>> of incrementing revision numbers.  The following is a proposal to add this 
>> feature to Git.
>> 
>> 
>> Rationale:
>> 
>> Incrementing revision numbers (IRNs - an acronym I just made up) are 
>> useful in that they can be treated as auto-generated tags which are easier 
>> to remember and communicate than SHA hashes, yet do not require extra 
>> effort to create like real tags.  Also, they have the advantage of being 
>> chronologically ordered, so if I assert that a bug was fixed in revision 
>> 42 of a shared repository, everyone may assume that revision 45 has that 
>> fix as well.
> 
> That is true _only_ if you have linear history. If you have multiple
> concurrent branches, revision 42 can be in branch 'next', revision '45' in
> topic branch 'xx/topic' which forked before revision 42, and do not have
> the fix.

Additionally, what does _chronological_ mean? Time the commit is recorded?
Remember that in distributed development commits can be fetched from other
repository, or arrive via email and applied using git-am. In git you can
also rebase branch. Git records merges, and said merges are sometimes
just fast-forward. All those difficulties have to be solved for IRNs.

By the way, there was similar proposal to add either hidden field ('note'
like) to commit object denoting _generation_ of commit, or add cache of
commits' generation numbers. Generation number of root (parentless) commit
is 0, generation number of a commit is maximum of generation numbers of its
parents plus 1. But this proposal was for easier and faster generation of
topological order.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git