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

["Avery Pennarun" <apenwarr@gmail.com>]

On Thu, May 1, 2008 at 12:48 PM, Jeff King <peff@peff.net> wrote:
>  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