On Jan 11, 2014, at 4:26 PM, Eric S. Raymond 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).