Re: "git reset --hard" == "git checkout HEAD" == "git reset --hard HEAD" ???

[Junio C Hamano <gitster@pobox.com>]

Sitaram Chamarty <sitaramc@gmail.com> writes:

>>> It seems we have 2 ways to blow away work we haven't
>>> checked in yet then right?
>>
>> Wrong.
>
> Strictly as asked, yes, but what if he adds a "-f" to the
> middle command, making it "git checkout -f HEAD"?  Wouldn't
> that be the same as the others then?

Yeah, but comparing reset and checkout misses a whole _dimension_ in the
revision space continuum.

"git checkout <branch>" is primarily about checking out a different
branch, aka "switching branches".

When you switch branches, you generally do not want to lose your pending
changes, but would want to take them with you.  A typical scenario is that
you start looking at one issue, you fiddle a few lines here and twiddle a
few lines there, and as you dig deeper, you realize that whatever the
final shape of the change you are going to make will be either (1) big
enough to deserve its own branch created anew, or (2) better done as an
extension to an existing branch.  You realize that you are in the latter
situation by noticing that the modification you were making will be helped
by something you have implemented in the other branch but not yet
available in the current one (typically the latter is 'master').

In such a case, you will "git checkout <the-appropriate-topic>" to switch
to the branch, and you would want to take the change you already made to
your work tree files when you do so.

On the other hand, "git checkout -f <branch>" blows away your changes, but
it still _is_ about switching to a different branch.

Whether you use -f or not, you are allowed to ask to switch to the current
branch by (1) naming the branch explicitly, i.e. "git checkout -f master",
(2) using HEAD to mean the current one instead, or (3) omitting <branch>
altogether.  But that is there merely for consistency and, even though
there may not make much sense to do so (because it is largely no-op except
that you would get the "you are ahead by N" notice), there is no strong
reason to forbid asking for a no-op.

For that reason, "git checkout -f HEAD" is "blow away my changes".  But it
is merely a degenerated case of "switching to the current branch while
blowing away my changes."

"git reset --hard <commit>" is different.  "reset" is primarily about
pointing the tip of the current branch to somewhere else.  While "git
checkout <branch>" never changes what commit sits at the tip of any
branch, "git reset <commit>" modifies it for the current branch (--hard
variant matches the work tree files to the contents recorded by the
resetted-to commit while at it).

Again, you are allowed to ask to reset to the current HEAD by saying
"reset --hard HEAD".  That is a degenerated case of "resetting the tip of
the current branch, while blowing away my changes".  More general case
would be "reset --hard <some-commit>" and it won't just blow away your
changes (relative to the commit you started out with), but also blows away
the history leading to the commit the branch tip used to point at.

"checkout -f" and "reset --hard" work on different dimensions, and what
they do intersect when (and only when) the <branch>/<commit> argument
happen to be HEAD.  "checkout -f <another>" and "reset --hard <another>"
will do quite different things.