Re: [PATCH v2 3/4] reset: add option "--merge-safe" to "git reset"

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

Christian Couder <chriscool@tuxfamily.org> writes:

> But I think that it can be usefull in case like:
>
> $ "hack something"
> $ git commit ...
> $ "hack something else"
> $ git add "some of the files"
> $ "find out previous commit was crap"
> $ git reset --merge-safe HEAD^
>
> Here using "--merge-safe" can be usefull because you don't want to lose 
> stuff in your current index and work tree.

That depends on the reason why you are resetting away the "crap commit"
and what your next move is.

If you are going to run "git commit", perhaps after some further edit, in
order to fix what the "crap commit" did not quite do right, what your new
option does is actively a wrong thing to do.  "Some of the files" you
added after that "crap commit" are about "hack something else", i.e. not
part of the work to fix the "crap commit", and their changes should not be
included in the amended commit, no?

In general, "reset" should be about matching the index entries to the
named commit, so that you can start from the clean, known slate to redo
the commit you wanted to make on top of it.  You would need a very good
use case to deviate from it and leave the index entry different from that
of the commit you are switching to; otherwise you would greatly confuse
the end users.