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