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). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html