On Jonathan Nieder wrote:
> David D. Kilzer wrote:
>
> > With diff.renames = copies, a rebase with a file move will fail with
> > the following error:
> >
> > fatal: mode change for <file>, which is not in current HEAD
> > Repository lacks necessary blobs to fall back on 3-way merge.
> > Cannot fall back to three-way merge.
> > Patch failed at 0001.
>
> I would think that the following works fine:
>
> git init test-repo &&
> cd test-repo &&
> echo hello >greeting.txt &&
> git add greeting.txt &&
> git commit -m base &&
> git checkout -b move &&
> git mv greeting.txt moved.txt &&
> git commit -m move &&
> git checkout master &&
> echo hi >greeting.txt &&
> git add greeting.txt &&
> git commit -m change &&
> git checkout move &&
> echo '[diff] renames = copies' >>.git/config &&
> git rebase master
>
> What am I doing wrong?
Given the following tree:
B' topic
/
A---B master
A: New file "F1" is committed.
B: New file "F2" is committed.
B': New file "F2" is committed (identical in content to "F2" on B), and "F1" is
renamed to "F3".
When the topic branch is rebased onto master with diff.renames=copies, git fails
when attempting to build a fake ancestor for F1. The key to reproducing the bug
is to have an identical new file added on both B and B'.
My original patch in <http://marc.info/?l=git&m=122635667614099&w=2> addressed
this in builtin-apply.c, but Junio didn't like this approach as noted in
<http://marc.info/?l=git&m=122636097120953&w=2>.
> Patch does not apply to master or maint, due to conflict with
> v1.7.1-rc0~37^2~5 (rebase: support automatic notes copying,
> 2010-03-12). One sneaky way to avoid this kind of thing would be to
> insert new tests at some logical point in the middle of a test script.
Sorry about that--I forgot to rebase it to maint before sending it.
> Test nitpicks:
Thanks! I'll make the requested changes in the next patch.
> This wants to notice that Y was already added so the top patch can be
> simplified to include only a rename.
Actually, this is the key to reproducing the bug!
> Can you explain why this test will fail without your patch?
Here is a stand-alone script that reproduces the bug:
git init test-repo &&
cd test-repo &&
echo hello > F1 &&
git add F1 &&
git commit -m "A" &&
git checkout -b topic &&
echo hi > F2 &&
git add F2 &&
git mv F1 F3 &&
git commit -m "B'" &&
git checkout master &&
echo hi > F2 &&
git add F2 &&
git commit -m "B" &&
git checkout topic &&
git config diff.renames copies &&
GIT_TRACE=1 git rebase master
Note that the test case in my patch depended on "F1" (which was "A") being
committed by an earlier test.
Dave
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html