Re: rerere affects handling of git-stash-pop merge conflicts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



git rerere is misleading us after a conflicted 'git stash pop'. There _is_ an unresolved merge conflict, but .git/MERGE_RR exists and is empty, even though there is no previously recorded resolution. This causes git mergetool to skip over our conflicted file since he now uses 'git rerere remaining' to find the unresolved conflicts.

I think one of these is true, but I'm not sure which one.

  A. rerere _should not_ be triggered at all by "stash pop" conflicts
or
B. rerere _should_ be correctly and completely triggered by "stash pop" conflicts
or
C. 'git mergetool' should not be expected to work after a failed "git stash pop"

I'm hoping the right answer is B, but I would also accept A.

fwiw - 'git stash pop' calls 'merge-recursive' at the end, and this is where the problem appears. I have not decoded git-merge-recursive's use there enough to figure out where it's gone wrong.

Phil


On 07/14/2011 01:09 PM, Phil Hord wrote:
I was investigating a git-stash-pop anomaly when I ran across this one.
I think this is residual breakage from [1] bb0a484 (mergetool: Skip
autoresolved paths, 2010-08-17).  A similar problem aimed at 'git merge'
was ostensibly fixed by [2] 2f59c9 (mergetool: don't skip modify/remove
conflicts, 2011-02-16).

[1] http://thread.gmane.org/gmane.comp.version-control.git/153420
[2] http://thread.gmane.org/gmane.comp.version-control.git/164622


Summary:
After a 'git stash pop' with conflicts, 'git mergetool' fails to notice
the conflicted files if 'rerere.enabled=true'.  git mergetool
erroneously reports 'no files need merging'.

After a 'git merge' with conflicts, 'git mergetool' seems to work ok in
either case.

Here's my test script:

------8<------ /tmp/stash.sh
#!/bin/bash

#enable/disable rerere for this test
git config --global rerere.enabled ${1:false}

# run the test
rm -rf foo
mkdir foo&&  cd foo&&  git init&&
echo A>file&&  git add file&&  git commit --quiet -m "A"&&
echo B>file&&  git stash&&
echo C>file&&  git add file&&  git commit --quiet -m "C"&&
git stash pop

git mergetool
------8<------ /tmp/stash.sh

git --version
     git version 1.7.6.178.g55272

# With rerere.enabled=false, it works ok (mergetool offers to
# merge the conflicting file):
./stash.sh false

     Initialized empty Git repository in /tmp/foo/.git/
     Saved working directory and index state WIP on master: ac67a86 A
     HEAD is now at ac67a86 A
     Auto-merging file
     CONFLICT (content): Merge conflict in file
     merge tool candidates: meld opendiff kdiff3 tkdiff xxdiff
     tortoisemerge gvimdiff diffuse ecmerge p4merge araxis bc3 vimdiff
     emerge
     Merging:
     file

     Normal merge conflict for 'file':
       {local}: modified
       {remote}: modified
     Hit return to start merge resolution tool (xxdiff): ^C

# But with rerere.enabled=true, mergetool thinks there is no conflict:
./stash.sh true

     Initialized empty Git repository in /tmp/foo/.git/
     Saved working directory and index state WIP on master: d40e77b A
     HEAD is now at d40e77b A
     Auto-merging file
     CONFLICT (content): Merge conflict in file
     merge tool candidates: meld opendiff kdiff3 tkdiff xxdiff
     tortoisemerge gvimdiff diffuse ecmerge p4merge araxis bc3 vimdiff
     emerge
     No files need merging

Phil



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]