Actually, AFAICT from looking at the mailing list history, it's not dirty politics: the tie-breaker was the support and enthusiasm of the mercurial developers. It passed with only minor comment on the git mailing list, but it was a Big Thing to the hg folks. There are ups and downs. OpenSolaris is definitely the big fish in the mercurial pond (that wasn't *meant* to sound like a recipe for heavy metal toxicity), and will get lots of attention, but git has more real-world experience. The big fish in the git pond is Linus and Linux. In any case, mercurial and git are really very similar, far closer to each other than any third system, so it's not like the decision is a descent into heresy. Hopefully some useful cross-pollination can occur, and converting history from one to the other would be simple if anyone ever wanted to. As for explicit renames, people are confused on the subject. IMHO, the two most revolutionary things about git are: - Finally, a complete break from file-oriented history. History is made of trees, and trees are made of files. There is no direct connection between files in different commits. - An explicit representation of an in-progress merge. This is what makes multiple merge strategies easily implementable. Third, I suppose, is the raw diff format and the diffcore pipeline. But finally getting away from the SCCS & RCS idea that the file is the unit of history is one of git's Great Features, and it shouldn't be thrown away. What people who are asking for explicit rename tracking actually want is automatic rename merging. If branch A renames a file, and branch B corrects a typo on a comment somewhere, they'd like the merge to both patch and rename the file. If you can do that, you have met the need, even if your solution isn't the one the feature requester imagined. (This is the general consulting problem: a client calls when they've been trying a solution and can't get past some problem. Usually, this is because they've wandered into a blind alley, and what they're asking for is either far more difficult than necessary, or will just lead them into greater problems. The first thing you have to determine is what they actually want to do, as distinct from how they've decided to do it.) But, as Linus has pointed out, this is a very partial solution which introduces a lot of difficulties elsewhere. File renaming is a subset of the general class of code reorganizations. Source files will be split, merged, and have functions moved back and forth. You want the patch to find the code it applies to even if that code was moved. And that can be done by taking a more global view of the patch. Identical file names is only a heuristic. If the hunk on branch A can't find a place to apply on the same file in branch B, then you have to look a little harder, either at changes from branch B that introduce matching code elsewhere, or perhaps looking through history for a change that removed the match from the obvious place to see if it added a match elsewhere. The one thing that makes this difficult is git-read-tree's automatic collapse of "trivial" merges. If branch B moves foo() unchanged from x.c to y.c, while branch A doesn't touch y.c, but edits foo() in x.c, git-read-tree will collapse the changes to y.c before even invoking the advanced resolve script. (The solution might be to keep *four* versions of the file in the index: the three pre-merge, *and* the post-merge. Then git-write-tree makes sure everything has a stage 0 entry and strips out the stage 1, 2 and 3 entries. This way, one merge algorithm can use another as a subroutine but decide not to accept something it did.) But anyway, it's the merging that's the desired feature. Explicitly recording renames is only the means to that end, and is superfluous if there's another way of getting there. (And the place to look for interesting new ideas in that area Darcs.) - : 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