Re: Merging limitations after directory renames -- interesting test repo

[cc'ing Linus, who is usually interested in deep rename issues]

On Fri, Feb 18, 2011 at 01:58:48PM -0500, Martin Langhoff wrote:

s{git/}{} in your url.

Hmm. Two questions:

  1. Did you bump up your merge.renamelimit? It's hard to see because it
     scrolls off the screen amidst the many conflicts, but the first
     message is:

       warning: too many files (created: 425 deleted: 1093), skipping
       inexact rename detection

     which you want to use. Try "git config merge.renamelimit
     10000". Which runs pretty snappily on my machine; I wonder if we
     should up the default limit.

  2. Which version of git are you using? Commit 83c9031 produces some
     funky results on merges. It's not in any released version of git,
     but it is in master.

So assuming the two issues above are not a problem, merge says:

  CONFLICT (rename/delete): Rename
  trunk/etherpad/bin/rebuildjar.sh->etherpad/bin/rebuildjar.sh in
  origin/pg and deleted in HEAD

about this and many other files. But that doesn't seem right. Both sides did the same rename. But we don't seem to detect it on "master":

  $ base=`git merge-base master origin/pg`
  $ git diff -M --summary $base master | grep rebuildjar
   create mode 100755 etherpad/bin/rebuildjar.sh
   delete mode 100755 trunk/etherpad/bin/rebuildjar.sh

Hmm. That is probably because it was substantially rewritten:

  $ wc -l etherpad/bin/rebuildjar.sh
  161

  $ git diff --stat \
      $base:trunk/etherpad/bin/rebuildjar.sh \
      master:etherpad/bin/rebuildjar.sh
   .../etherpad => master:etherpad}/bin/rebuildjar.sh |   92 +++++++++++++-
   1 files changed, 89 insertions(+), 3 deletions(-)

You can ignore the rename-looking bit in the diffstat; it's an artifact of the way single-blob diffs are done. But the important thing to note is that it was mostly rewritten on the master branch, and that's why the rename isn't found.

This seems like an interesting case with respect to git's philosophy of automatic rename detection. Usually the notion of "if it is so far apart that we can't do rename detection, a 3-way merge is not likely to be interesting" works.

But in this case, that may not hold. We have identical renames on either side, but one side has been modified a lot. The 3-way merge may very well be useful, but we never get there, because we don't even consider that the two endpoints may be related.

You can simulate the 3-way merge that would happen with:

  $ git show origin/pg:etherpad/bin/rebuildjar.sh >pg
  $ git show master:etherpad/bin/rebuildjar.sh >master
  $ git show $base:trunk/etherpad/bin/rebuildjar.sh >base
  $ git merge-file master base pg
  $ $EDITOR master

It's an ugly merge, but way more useful than dumping with a rename/delete conflict.

I'm not sure of the right solution. I guess if there was some way to say "no really, these are renames" it would make your merge easier. But I wonder if we can somehow be more clever.

I think this is a side effect of the rename/delete conflict. There is nothing to diff against on one side.

-Peff