Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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? >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html