Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 3, 2012, 19:03 UTC
Message-ID: <7vhaqb4bvb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7v391v5rgb.fsf@alter.siamese.dyndns.org>

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

Show 7 quoted lines

> Phil Hord <phil.hord@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

    http://thread.gmane.org/gmane.comp.version-control.git/185825/focus=185863,

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).