Re: [PATCH] Documentation/git-merge.txt: weaken warning about uncommited changes

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 18, 2013, 14:57 UTC
Message-ID: <7vmwqn8o18.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpqppvju794.fsf@anie.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 15 quoted lines

> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Matthieu Moy wrote:
>>> Weaken the warning by discouraging only merge with /non-trivial/
>>> uncommited changes.
>>>
>>> I don't think documenting all the failure cases in the doc would be a
>>> good idea, so I've left the "in some cases" part.
>>
>> It's already documented in the pre-merge checks section, as Jonathan
>> pointed out [1]. 
>
> I had missed this one. But that's not the only case, you may also have
> problems with renames. The complete list would be really long to have
> here, and won't bring much to the user.

True.

After having re-read the thread up to the message from Jonathan, I suspect that a "merge" half of "pull --autosquash" series (which had to be dropped) was based on a misunderstanding and we didn't have to have that discussion if the documentation were a little less discouraging about merging in a dirty working tree?

Show 7 quoted lines

>> We should update the documentation to point to it: I do not think
>> "non-trivial" is much of an improvement.
>
> Actually, I think it essentially says it all. If your changes are
> important enough to deserve a real backup, you should stash or commit.
> If you're ready to take the risk of losing it (the risk is small, but
> does exist), it's OK to run "git merge" blindly.

Your documentation update makes sure that we are less discouraging, I think. It does not have to be the only phrasing (hinting others to try to come up with a beeter version if they are so inclined), but it is going in the right direction.