I'm surprised that the author of this post would point out a rename conflict as something that "git gets right", in part because I'm relatively certain that git-merge-recursive did not exist when this this mailing list exchange occurred (I'm actually surprised that it was the default already in 2007) and git-merge-resolve would have done something completely different, treating `greeting` as deleted in both and `saludo` as added in left. There would be no conflicts and `saludo` would merrily be created, which seems like the wrong thing.
But I'm mostly surprised because rename conflicts are this transient thing. git-merge-recursive will detect a rename conflict, but you're hosed when it comes time to resolve it, since the information that it's a rename conflict isn't captured anywhere except, briefly, in the phosphors of your CRT.
In the author's example, when you run `git status`, it will simply tell you that `saludo` was added by them. Which is exactly the behavior of the rename-deficient git-merge-resolve. The expectation in resolving this, I suppose, is that you saw the message that this was a rename/delete conflict, remembered the original filename and could somehow make a decision based on that.
This is not terrible in a rename/delete conflict, but for some other types of rename conflicts, it's much more difficult. For example, branch 'A' renames a file from 'foo' to 'bar', branch 'B' renames it from 'foo' to 'baz'. Now you have two files in your working directory and git-status can only tell you that they were each added, which is not indicative of a conflict.
This is annoying for a user on the console. This is impossible for somebody trying to build a UI to resolve a merge conflict: 'bar' was added in one of the branches... why does this conflict? Well, if it's only on one side of the merge, then it must have come from some rename conflict. But with which other file? What's the common ancestor that git-merge-recursive decided was a rename? Meh.
(Please do not mistake this rant as a suggestion that Codeville's merge is superior to Git's. I'm not suggesting that, just that git-merge-recursive has a few rough edges that could use polish.)
That's exactly the point: Git didn't handle the rename conflict so well at the time of the mailing list exchange, but it did handle it better by the time the blog post was written. And it may handle it better still in the future, precisely because the repo format isn't laden with metadata[0], and the handling of edge cases like this can be improved by evolving the heuristics that Git uses to infer what happened.
It's a bet that "future self" (improving heuristics) will be more effective than "past self" (attempting to design a future-proof the repo format). It looked like the bet was paying off in 2007 when the blog post was written, and 7 years later that still seems to be the case.
[0] Metadata which would need to be carefully managed for compatibility across versions, and which would be missing any time the user forgot to explicitly record it (with a Git command) and instead made a change directly to the worktree.
Yeah, we're in agreement about that. The simplicity of the git repository is very nice. The repository format is a thing so beautiful that it makes you want to cry.
With a few horrible warts thrown in that make you actually cry.
But I'm mostly surprised because rename conflicts are this transient thing. git-merge-recursive will detect a rename conflict, but you're hosed when it comes time to resolve it, since the information that it's a rename conflict isn't captured anywhere except, briefly, in the phosphors of your CRT.
In the author's example, when you run `git status`, it will simply tell you that `saludo` was added by them. Which is exactly the behavior of the rename-deficient git-merge-resolve. The expectation in resolving this, I suppose, is that you saw the message that this was a rename/delete conflict, remembered the original filename and could somehow make a decision based on that.
This is not terrible in a rename/delete conflict, but for some other types of rename conflicts, it's much more difficult. For example, branch 'A' renames a file from 'foo' to 'bar', branch 'B' renames it from 'foo' to 'baz'. Now you have two files in your working directory and git-status can only tell you that they were each added, which is not indicative of a conflict.
This is annoying for a user on the console. This is impossible for somebody trying to build a UI to resolve a merge conflict: 'bar' was added in one of the branches... why does this conflict? Well, if it's only on one side of the merge, then it must have come from some rename conflict. But with which other file? What's the common ancestor that git-merge-recursive decided was a rename? Meh.
(Please do not mistake this rant as a suggestion that Codeville's merge is superior to Git's. I'm not suggesting that, just that git-merge-recursive has a few rough edges that could use polish.)