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)
            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
More majordomo info at

Reply via email to