On Tue, 19 Sep 2006, Shawn Pearce wrote:
Joel Dice <dicej@xxxxxxxxxxxxx> 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.
I can't say I miss that particular feature. Abbrevations of
SHA1 IDs tend to work very well for the projects I use Git on;
6-8 characters is easily more than enough to uniquely identify
a revision. Heck half the time even 4 hex characters is enough.
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.
But with respect to what branch?
Branches in a Git repository are very common:
o------o-o-o-o-o-o--- B1
/
-o--o--o-----o--------o B2
Assuming the branch point on the left was r60, what is the latest
commit on B1? On B2? What about if I merge B1 and B2 together?
Branches in Subversion are also very common. The "last changed" IRN for a
branch is the index of the head of the branch in the history.
Or are you proposing that the commits are ordered by the time that
they arrive into the repository?
Yes.
But even if that's the case lets say I fix the bug on B1 in r42
but a commit on B2 gets assigned r45. The bug isn't fixed in r45;
not unless B1 was merged into B2 in r43, r44 or r45. But there's
no way to know that from just an IRN.
I fail to see how IRNs simplify commit naming or determining where
a feature or bug fix is within the branching structure.
I'm not suggesting that an IRN stand on it's own in this way. Additional
context may be necessary depending on the situation. It's intended as a
convenience, not a replacement for the SHA IDs.
A simple, efficient implementation of this feature would be based on a
single file, $GIT_DIR/history, which would contain a newline-delimited
list of SHA commit IDs in chronological order, oldest first. The current
repository IRN would be calculated as the size of that file divided by the
SHA+newline length, and the commit ID of any IRN could be determined by
seeking to the correct offset in that file. Every commit would cause a
new line to be appended to the history file with that commit's ID.
Finally, a history file could be generated for an existing repository by
serializing the commit history based on chronological order.
How about just using bare tags under the namespace 'refs/tags/r/'?
With the new packed refs implemention these would cost you a tiny
amount of overhead over what you propose (due to the ref name also
being stored) but its already implemented and does the job just
as well.
Good idea. I'll try that.
- 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