Re: [PATCH 2/2] user-manual: Document that "git merge" doesn't like uncommited changes.

Junio C Hamano [off-list ref] writes:

"but not the working tree itself" is not incorrect per-se, but misses the
point.  How about...

	A merge is made by combining the changes made in "branchname" and
        the changes made up to the latest commit in your current branch
        since their histories forke.  The work tree is overwritten by the
        result of the merge when this combining is done cleanly, or
        overwritten by a half-merged results when this combining results
        in conflicts.  Therefore, ...

Maybe better. OTOH, it reveals another problem: Your "the work tree is
overwritten by ..." tend to imply that the result is not commited,
while the normal case is indeed to create a merge commit
automatically.

In its current state, the doc jumps to conflict resolution and how to
commit after resolving them without saying "oh, normally this is over,
Git did the commit for you". And for people comming from SVN, thinking
"merge = update", it's not obvious at all that a merge should result
in a commit.

So, I'll resend with one more paragraph talking about autocommit.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/