Re: Subversion-style incrementing revision numbers

[Joel Dice <dicej@mailsnare.net>]

On Wed, 20 Sep 2006, 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.

In practice, this is not a problem.  The branch referred to is usually 
understood from the context (ex. a Bugzilla bug for a particular version 
of a product implies a particular branch).  Otherwise, yes, you must also 
explictly state which branch the fix was applied to.

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

I would suggest that most repositories are centralized.  They're just not 
using Git yet :)

  - Joel