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

From: Jeff King <peff@peff.net>
Date: May 1, 2008, 22:42 UTC
Message-ID: <20080501224215.GB21731@sigill.intra.peff.net>
In-Reply-To: <32541b130805011245j76421635me55947cf7869f31f@mail.gmail.com>

On Thu, May 01, 2008 at 03:45:07PM -0400, Avery Pennarun wrote:

Show 5 quoted lines

> In your example above, we compare the merge-base to the new version;
> in that case, the new file is in an *existing* directory which
> definitely corresponds to src/ in #1, because the the new version has
> never even heard about src/ being deleted.  Thus, the file must be
> intended to be part of the original src/, wherever it may now be.

I disagree with the final statement of the quoted paragraph above.

Just because you didn't build on the commit that moved src/* doesn't mean the thing you put in src/ was intended to be moved along with src/. For example:

  - it might have been a new work unrelated to the existing work in src/
    that got moved

  - it might have been a replacement for the work in src/ that was
    started before the movement. E.g., developer1 begins the replacement
    work. developer2 moves the old work out of the way. When the
    branches are merged, you don't want developer1's work moved.

And yes, I think those are probably less common than "it should be moved along with src/*". My point isn't that this isn't a valuable construct, but that we should stop short of mind-reading, and focus on making it _easy_ to see what happened and to concisely specify the choice and proceed.

-Peff