1

I understand that by default unless a previous commit is checked-out, HEAD is the latest commit on the currently checked-out branch.

What is the difference between:

  • git reset HEAD
  • git reset HEAD~

My understanding:

The first command will reset latest commit - why would anyone do this? Unless for example HEAD is made to point to another place using checkout command prior to running this reset command. Correct?

The second command will reset the commit prior to the head, effectively the latest commit will now be orphaned. Correct?

LeGEC
  • 46,477
  • 5
  • 57
  • 104
variable
  • 8,262
  • 9
  • 95
  • 215
  • 2
    Does this answer your question? [What's the difference between HEAD^ and HEAD~ in Git?](https://stackoverflow.com/questions/2221658/whats-the-difference-between-head-and-head-in-git) – Edric Sep 29 '22 at 07:30
  • 2
    No commit will be destroyed, with either command. The first one will *unstage* everything. The second one will also make current branch point one commit "back", following ancestry (so current commit's parent. – Romain Valeri Sep 29 '22 at 07:34
  • @Edric Not convinced it's a close enough duplicate, because of `git reset HEAD` which is not adressed. – Romain Valeri Sep 29 '22 at 07:35
  • 1
    I don't know about `git reset HEAD`, but `git reset --hard HEAD` (or simply `git reset --hard`) is terribly important and useful; I say it every day. – matt Sep 29 '22 at 08:02

1 Answers1

3

git reset X is identical to git reset --mixed X. Looking at the documentation, that is:

git reset [<mode>] [<commit>]

This form resets the current branch head to <commit> and possibly updates the index (resetting it to the tree of <commit>) and the working tree depending on <mode>. If <mode> is omitted, defaults to --mixed. The <mode> must be one of the following:

--mixed

Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.

If -N is specified, removed paths are marked as intent-to-add (see git-add).

So, git reset --mixed resets marks all staged changes as unstaged again. git reset --mixed HEAD is identical. git reset --mixed HEAD^ moves your HEAD back by one (following the first parent).

Executing git reset HEAD^ will lose the commit that was HEAD at the time this command is executed, unless it is reachable from other refs (branches, tags).

knittl
  • 246,190
  • 53
  • 318
  • 364
  • Ok so `git reset --mixed HEAD` has no impact on the committed things. – variable Sep 29 '22 at 08:49
  • @variable correct. It will move HEAD to HEAD, which is not really moving it :) – knittl Sep 29 '22 at 08:51
  • 1
    When you are in the middle of a merge, `git reset HEAD` also has an effect on *conflicting files* : it clears the inner conflict flags in the index, which allows you to unlock some other actions. Be aware, though, that you haven't *fixed the conflict* (the content of your file at least), and that your file will still contain conflict markers (`<<<<<<< HEAD`, `>>>>>>> thatothercommit`) and partial chunks from both versions. – LeGEC Sep 29 '22 at 14:18