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

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 1, 2008, 19:45 UTC
Message-ID: <32541b130805011245j76421635me55947cf7869f31f@mail.gmail.com>
In-Reply-To: <20080501164829.GA11636@sigill.intra.peff.net>

On Thu, May 1, 2008 at 12:48 PM, Jeff King <peff@peff.net> wrote:

Show 13 quoted lines

>  I don't see it. I think the steps are exactly the same as in your
>  example. Consider:
>
>   1. You have some files in src/
>   2. All of the files from src/ get moved away
>   3. You merge in somebody else's work which adds a file in src/, but
>      their work is based on a commit which predates 2.
>
>  The question is: if they had seen 2., would they have put the file into
>  src/, or into the new location? I think the answer depends on the
>  semantics of the file. If it is semantically an addition to the source
>  code that got moved, then yes. If it is a _replacement_ for the
>  source code that got moved, then no.

I promised I would shut up, and I apparently didn't.  Sorry :)

I think this case isn't so hard. Basically, a merge involves three commits; the merge-base, my branch, and your branch.

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.

In contrast, if the merge-base already had src/ being renamed, and someone put something into src/, we'd know that they're putting it into a fundamentally different directory than the moved src/.

Exactly how you track the "identity" of a directory without breaking things down by individual commit sounds a little complicated, but it feels to me like it should be possible.

I suspect this is a generalization of the earlier discussion (a few months ago) that I read in the archive about git's handling of empty directories. Right now git does weird things with directory creation/deletion because directories are not first-class citizens.

Anyway, as with the empty directory stuff, if I occasionally have to mkdir/rmdir a couple things and rename a few files after doing a merge, I'm not going to cry too much. It sure beats explicitly tracking renames and then having an oops-I-forgot-to-explicitly-track rename throw a monkey wrench into my merges, which svn has saddled me with lots of times.

Have fun,

Avery