On Thu, May 01, 2008 at 12:12:33PM -0700, Steven Grimm wrote:
> 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
I do agree that the rename is probably more often desired.
> 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.
Yes, I think that is largely a correct impression (although I think
Linus has spoken out against directory renaming in the past, so there is
at least a little bit of conscious effort). I suspect the right sequence
of steps to implement this would be:
1. write a proof-of-concept that shows directory renaming after the
fact (e.g., take a conflicted merge, scan the diff for directory
renames, and then fix up the files). That way it is available, but
doesn't impact git at all.
2. If people think it is useful, build it into the diff and merge
machinery so that it can happen automagically, but make it
optional. Thus git fully supports it, but the policy decision is
left up to the user.
3. Make it the default if it is the common choice.
So we just need somebody to volunteer to work on 1. ;)
-Peff
--
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
