Matthieu Moy <> writes:

> Ramkumar Ramachandra <> 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.


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?

>> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to