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

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

That is discarding your changes and also the last commit.

I do not think this has a clear meaning. "discard the last commit but leave the contents in the working tree. I do not care a newly added files are forgotten by the index, I'll remember to re-add them if I need to" is what you are saying here, but the word "index" does not hint it. When used as an option name, "--index" means "this command usually works on or touches working tree but for this invocation please also affect the index"; "please look at or affect _only_ the index" is usually spelled "--cached".

In any case, I think your proposal makes it even worse than the current state, and you should aim higher. Some modes of "git reset" have historical reasoning behind their behaviour that cannot be dismissed easily by somebody who does not understand them, but at the same time some of them outlived their usefulness and we may want to start thinking about deprecating them. The first step might be to make them less prominent in the documentation.

I am guilty of introducing "git reset --soft HEAD^" before I invented "commit --amend" during v1.3.0 timeframe to solve the issue "soft" reset originally wanted to. Even though the whole point of the "reset" command is about "resetting the index", it is an unfortunate oddball that does not touch the index. It shouldn't have been part of the "reset" command, and if we were doing Git from scratch today, we probably wouldn't have it there. What it does is sometimes useful in interactive use and often useful in scripting, but scripts can use update-ref.

"git reset --hard HEAD" is an unambiguously descriptive good name for the option. It is a "hard reset" like power cycling a machinery to discard anything in progress and get back to a clean slate. I do not see anything confusing with this mode nor its name.

"git reset --keep" was introduced at 9bc454d (reset: add option "--keep" to "git reset", 2010-01-19) as a short-hand to run something like this.

    git checkout -B $current_branch $target_commit

If we made the above command line to work (it errors out saying you cannot update the current branch) instead of adding it a new mode to "reset", it would have been much easier to understand what the particular operation does. You are updating the tip of the branch that happens to be the current branch to a different commit while carrying the local change with you.

It also would have made number of options "reset" has smaller by one and reducing confusion. What it does is too similar to what "reset --merge" does, which only adds to the confusion.