Junio C Hamano <gits...@pobox.com> writes:

> Phil Hord <phil.h...@gmail.com> writes:
>> I flagged this for followup in my MUA, but I failed to follow-up after
>> the holidays. I apologize for that, and I really regret it because I
>> liked where this was going.
> I really regret to see you remembered it, actually.

Having said that, I am glad that you brought the old discussion
thread to our attention.  In


I said that "git reset --keep" started out as an ugly workaround for
the lack of "git checkout -B $current_branch".  Now we have it, so
we can afford to make "reset --keep" less prominently advertised in
our tool set.  As I already said back then, "reset --soft" also has
outlived its usefulness when "commit --amend" came, so that leaves
only these modes of "reset":

        reset --hard [$commit]
        reset [$commit]
        reset --merge

I am not sure if it makes sense to give a commit different from HEAD
to "reset --merge", and to a lessor degree, "reset --mixed" to flip
the HEAD to another commit while retaining the working tree contents
does not make much sense, either, in a common workflow.

It _might_ be possible to merge the --mixed and --merge if we think
things through to reduce the often-used options even further, but I
haven't done so, and I suspect nobody has (yet).

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to