Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > Junio C Hamano schrieb: >> As we established in the previous round, this is _different_ from --merge, >> but *not* in the sense that --merge is more dangerous and users should be >> using this new option instead, but in the sense that --merge perfectly >> works well for its intended use case, and this new option triggers a mode >> of operation that is meant to be used in a completely different use case, >> which is unspecified in this series without documentation. >> >> In that light, is --merge-safe still a good name for the option, or merely >> a misleading one? > > Do I understand this correctly? > > (1) The intended use-case of --merge is to "reset _a_ merge". See my review comment for the previous round where I described the intended use case of "reset --merge" and explained why discarding the changes to the index is _the right thing_. It is to throw away the changes that was done to your index by an either completed or conflicted merge. > (2) The intended use-case of --merge-safe is to point the branch head to a > different commit, but to carry the changes that currently are in the index > and wd over to the new commit, similar to checkout --merge. I have _no_ idea what the intended use-case of --merge-safe is, and that was why I asked Christian for clarification in the previous round. The answer was still not clear enough so I pointed out --merge-safe could be still doing a wrong thing even in _his_ use-case. -- 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