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

[Jeff King <peff@peff.net>]

On Thu, May 01, 2008 at 11:50:31AM -0400, Avery Pennarun wrote:

> I would argue that this is a sort of "directory splitting" operation.
> That is, all anyone ever did was add some files to a subdir/ that
> already existed [1], *or* move all the files from subdir/ to a
> previously-empty bettername/ [2], *or* create a new subdir/ and add
> files to it [3]. In each case, no merge operation was necessary and it
> is completely obvious by comparing "before and after" trees which case
> it was.

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 guess my argument here is just that it should be *possible* to
> deduce and implement both cases at merge time just fine using git's
> existing storage model.  It just hasn't been implemented yet.  (And
> incidentally, I think that's totally awesome and I'd never want to go
> back to an explicit rename tracking model.)

I think you lack information to decide automatically between the two
cases listed above. But I think in most cases it would be sufficient for
the tool to say "this directory seems to have moved, but this new file
was added in it" and let the user decide which makes sense.

> I should shut up now because the actual merge machinery scares me and
> I'm not willing to volunteer to write a patch for this one :)

It would probably start not with merge machinery, but with diff
machinery to detect "directory has moved". But that is also scary. :)

You could also do this totally _outside_ of git, similar to
git-mergetool. Wait until you get a conflict, and then run a script
which looks at the two endpoints and the merge base and says "Oh, maybe
this is a good way of resolving."

-Peff