Jeff King <p...@peff.net> writes:

> On Thu, Jun 20, 2013 at 03:33:34PM +0200, Thomas Rast wrote:
>
>> >> I naively would have expected this to leave us in a conflicted state
>> >> over "file".  But I guess read-tree just rejects it, because we are not
>> >> doing a real three-way merge.  I'm not sure it is that big a deal; this
>> >> is more about safety than about creating a conflicted/resolvable state.
>> >
>> > Note that the test_must_fail essentially tests that the merge is rejected.
>> 
>> Bah, no it doesn't, a conflicting merge also returns a nonzero status.
>> Sigh.
>> 
>> If you meant we should actually conflict,
>
> Yes, that's what I meant.
[...]
>> diff --git i/git-pull.sh w/git-pull.sh
>> index 1f84383..b3d36a8 100755
>> --- i/git-pull.sh
>> +++ w/git-pull.sh
>> @@ -276,7 +276,7 @@ then
>>      # lose index/worktree changes that the user already made on
>>      # the unborn branch.
>>      empty_tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904
>> -    git read-tree -m -u $empty_tree HEAD || exit 1
>> +    git merge-recursive $empty_tree -- $(git write-tree) HEAD || exit 1
>
> I don't think there is any advantage to using merge-recursive over
> read-tree here, in the sense that there cannot be any interesting
> content-level merging going on (our ancestor is the empty tree, so we
> know that differing content cannot be resolved).
>
> So I think you could just use read-tree with a 3-way merge, but I cannot
> seem to provoke it to leave a conflict. Hrm.

I guess read-tree doesn't consider that its job; it leaves the conflict
in the index alright for me if I do this:

 git-pull.sh     | 4 ++--
 t/t5520-pull.sh | 5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git i/git-pull.sh w/git-pull.sh
index 1f84383..4047d02 100755
--- i/git-pull.sh
+++ w/git-pull.sh
@@ -275,8 +275,8 @@ then
        # and try to fast-forward to HEAD.  This ensures we will not
        # lose index/worktree changes that the user already made on
        # the unborn branch.
-       empty_tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904
-       git read-tree -m -u $empty_tree HEAD || exit 1
+       empty_tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904 &&
+       git read-tree -m -u $empty_tree $(git write-tree) HEAD || exit 1
        exit
 fi
 

But it won't write the conflict markers in the worktree.

On the topic of "do we want to conflict": one issue is that we don't
have a prior state to go to, since it was never committed.  Not even the
implicit empty tree can be passed to 'reset --keep'.  So it might be
better to *avoid* creating conflict hunks -- and fail -- so as to avoid
giving the user a state that is hard to back out of.

In the same spirit I would also support this:

> I wonder if it would make sense to update HEAD only _after_ we had
> resolved successfully. As it is now, you are left in a weird state where
> pull has reported failure, but we actually update the HEAD (and "git
> status" afterwards reflects that you are building on top of the pulled
> HEAD).

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to