Subject: Re: [PATCH] Documentation/git-merge.txt: Expand the How Merge Works section

From: Junio C Hamano <[email-masked]>
Date: Fri, 18 Jul 2008 17:32:19 -0700

Petr Baudis <[email-masked]> writes:

>> However, I think we may want to talk about "How to tell if your merge did
>> not even touch your index nor working tree" somewhere in the manual.
>> "When there are conflicts, these things happen" part talks about how to
>> resolve conflicts, but when merge refuses to avoid losing local changes,
>> the instruction in that part does not apply.
>
>   I'm not sure if this is worth pondering about? The action would feel
> rather obvious to me - get rid of the local changes somehow, either
> committing them or stashing them or wiping them out. Is that worth
> elaborating, or is there more to it?

Oh, the necessary action is obvious.  That's not the issue.  You either
forget about the merge and in that case your index and working tree is
intact and you can keep going.  Or stash to merge first.

But what I was wondering was if we have given the users enough clues to
tell if the above is the right action.  If merge started and conflicted,
then forgetting about it and keep going is _not_ the right thing, and the
user needs to be able to tell these two very distinct cases apart.