Junio C Hamano <[email protected]> writes:
> Phil Hord <[email protected]> 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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
