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