Re: [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 17, 2009, 07:07 UTC
- Message-ID
- <7vr5u6jbgk.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4AB1D957.20902@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
Show 14 quoted lines
> 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.