It seems that we have a corner case bug in two-way merge to reset
away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".
In a freshly created repository:
rm -f A Z
for i in $(seq 100)
do
echo hello
done >Z
git add Z
git commit -m initial
git branch side
echo goodbye >>Z
git commit -a -m changed
git checkout side
git mv Z A
echo kitty >>A
git commit -a -m side
if you do one of these:
git checkout master && git merge side
git checkout side && git merge master
you will get three stages for path A, and nothing for path Z.
With the former, you are starting from a tree with Z (and not A),
and "resetting" should give you A that is the same as 'master' in
the working tree. With the latter, you are starting from a tree
with A, and "resetting" should give you Z and remove conflicted A
from the working tree.
git read-tree -u --reset ORIG_HEAD
does the right thing in either case, but
git read-tree -u --reset HEAD ORIG_HEAD
dies with "cache entry has null sha1: A" for both cases.
The direct symptom comes from 4337b5856f88 (do not write null sha1s
to on-disk index, 2012-07-28), but I think the root cause is
somewhere else. When we start from 'side', we should notice that
our HEAD has Z, and conflicted A we see in the index came from a
conflicted merge that we are resetting away and should disappear
from the working tree. When we start from 'master', we should
notice that we do not want to keep the cache entry that is
"modified" in the index, and write the one taken from the "going to"
tree (ORIG_HEAD).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
