Re: Subversion-style incrementing revision numbers

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

> Unfortunately, one cannot (as of now) use result of git-describe as
> <commit-ish>. I'd rather have it fixed, than port idea from _centralized_
> SCM do distributed SCM.
>
>> Proposal:
>>
>> As with Subversion, the IRN state in Git would be specific to a given
>> repository and have no significance beyond that repository.  Also like
>> Subversion, IRN state would be global across a repository, so that a
>> commit to any branch would increment the current IRN value.  Every Git
>> command taking a revision parameter would accept an IRN using a syntax
>> such as "r$IRN".  Every commit would report the IRN to the user as well as
>> the SHA ID.  The IRN feature could be enabled or disabled via a
>> configuration option.
>
> This of course limits IRN much. Tags are valid across repositories.
> I'm not sure if many repositories are managed using shared repositories
> (centralized approach).