merge renamed files/directories? (was: Re: detecting rename->commit->modify->commit)

> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>