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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:

> Junio C Hamano <gitster@xxxxxxxxx> 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.

Fair enough.  How about changing this part

>>         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

to

	The work tree is overwritten by the result of the
        merge when this combining is done cleanly, and the result is
        committed. Otherwise it is
	overwritten by a half-merged results when this combining results

?        
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]