On May 1, 2008, at 8:34 AM, Jeff King wrote:
So I don't think you can always track the intent automatically.
That is absolutely true. You have to pick one case or the other as the default unless there's some way to tell the system your intent either at merge time or at move time.
However, that leaves the question of which default will be wrong the least often.
In my personal experience, I think a directory rename has almost always meant that I would want new files to appear in the new directory rather than to recreate the old directory. I can't think of a single time when I've wanted git's current behavior (though maybe it's happened on occasion) but the current behavior has tripped me up more than once and forced me to do extra work shuffling things around by hand post-merge. I acknowledge that there exist cases where the current behavior is correct -- but in my experience they're the minority.
Of course, the discussion is moot anyway until someone writes code to detect the situation; my impression is the current behavior is the way it is simply because it's what naturally happens in the absence of merge-time detection of a directory getting renamed.
-Steve -- 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
