Re: detecting rename->commit->modify->commit

From: Jeff King <peff@peff.net>
Date: May 1, 2008, 23:14 UTC
Message-ID: <20080501231427.GD21731@sigill.intra.peff.net>
In-Reply-To: <D0968007-2A38-44DB-B26F-3D273F20D428@midwinter.com>

On Thu, May 01, 2008 at 12:12:33PM -0700, Steven Grimm wrote:

Show 5 quoted lines

> 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