Philippe Vaucher <philippe.vaucher@xxxxxxxxx> writes:
> So if I recap my ideas:
>
> "I want to discard my changes" --> git reset --all HEAD^
That is discarding your changes and also the last commit.
> "I want to discard the last commit" --> git reset --index HEAD^
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html