Re: Bazaar references complicate the git transition

[David Reitter]

On Jan 11, 2014, at 4:26 PM, Eric S. Raymond <address@hidden> wrote:
> 
> What you're suggesting seems to me like the best medium-timescale choice
> anyone has offered.  But here are some longer-scale problems with it:
> 
> 1. Tags are much more fragile than IDs in commit comments.  They could
> easily get deleted by someone's typo or moment of inattention.

It's an asymmetry shared with references to bug IDs, URLs (debbugs...), or 
e-mail addresses of committer names.

If tags get lost, someone can easily push them again.  It's a d-VCS after all.

> 2. What happens when people have forgotten the syntax of a Bazaar
> revision ID?  It's just a bare decimal integer, after all. Suppose a
> future VCS also uses commit IDs in this form?

If we're not automatically converting anything, future readers of a commit 
message, if they happen to come across the evidently rare reference to a bzr 
revid, will have to parse it and translate to the "bzr/#" git tag.

Mistakes happen, including inadequate commit messages, or simply bugs in the 
commits.
DVCSs fossilize the errors, in code and text alike.  That's okay!

> My practice for the last several conversions I've done has been to change
> all native revision IDs inline to these timestamp!committer pairs.

As you know, git is conceived around the notion of globally unique hashes to 
refer to a commit and the state of the history at the time.  It's one of the 
elegant ideas behind git that make it work so well.  Please do not rewrite 
history.

I had to stitch together two repositories when switching from one Emacs git 
mirror to the official one.  My repository still carries both conversions, and 
I don't see a way to get rid of them (without breaking hashes, and probably not 
at all unless git can migrate merges with lots of conflicts).

signature.asc
Description: Message signed with OpenPGP using GPGMail