Re: Subversion-style incrementing revision numbers

[Joel Dice <dicej@mailsnare.net>]

On Wed, 20 Sep 2006, Jakub Narebski wrote:

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

Yes.

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

All of these boil down to pointing the head of a branch to a new commit 
object, right?  I'm simply proposing that every time this happens, that 
new commit object (which may not really be *new*), should be appended to 
the IRN history file, along with any commits attached to it (as in the 
cases of fetch, etc.).

  - Joel