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

From: Jeff King <peff@peff.net>
Date: May 1, 2008, 16:48 UTC
Message-ID: <20080501164829.GA11636@sigill.intra.peff.net>
In-Reply-To: <32541b130805010850q165fe1d6me05e670ca93b0892@mail.gmail.com>

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

Show 7 quoted lines

> 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.

Show 5 quoted lines

> 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