Jeff King <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html