Re: [PATCH 3/3] reset: Print a warning when user uses "git reset" during a merge

[Junio C Hamano <gitster@pobox.com>]

Andrew Wong <andrew.kw.w@gmail.com> writes:

> On Fri, Mar 14, 2014 at 10:33 AM, Marc Branchaud <marcnarc@xiplink.com> wrote:
>> I know this approach was suggested earlier, but given these dangers it seems
>> silly to give this big warning on a plain "git reset" but still go ahead and
>> do the things the warning talks about.
>>
>> Is there any issue with changing "git reset" to error-out now but letting
>> "git reset --mixed" proceed?  Something like (note the reworded warning message):
>
> Yeah, I would have preferred to have "git reset" error out right now,
> because the messed up work tree can be quite a pain to clean up. The
> main argument for issuing the warning is about maintaining
> compatibility.
>
> For the users that really did mean "--merge", the warning is silly.
> It's basically saying "We know that you're about to mess up your work
> tree, but we let you mess up anyway. Learn the correct way so that you
> don't mess up next time".

I suspect that you meant "--mixed" instead of "--merge" here.

I do not agree with the "We know that you are about to mess up"
above.  Whoever is issuing that warning message may not know better
than the user who is running "reset".  As you wrote "most likely not
what the user wants" in your proposed log message, the only thing we
know is that it _often_ is a newbie mistake.

I recently needed to manually cherry-pick only one half of a patch,
and the way I did so was

	git show $that_commit >P.diff
        git apply -3 P.diff
        ... conflicts are expected; that is why I used -3 in the
        ... first place
        git reset
        git diff HEAD
	edit
        ... edit away the other half I did not want to cherry-pick
        ... while fixing the conflicted parts that happened to be
        ... in the part I did want to cherry-pick

"git cherry-pick --no-commit $that_commit" could have been used as
a replacement for the first two steps but being able to run the
"reset" without erroring out was an essential part to make this
workflow usable.

So I am OK with "eventually error out by default", but not OK with
"we know better than the user and will not allow it at all".