Why am I explicitly invoking git reset --soft before git reset (--mixed)

Question

In git docs (and many SO threads) it is recommended to use this reset approach:

$ git reset --soft HEAD^ ;# go back to WIP state <2> $ git reset <3> 

0.2. This removes the WIP commit from the commit history and sets the working tree to a state just before you take this snapshot.

0.3. At the moment, the index file still has all the WIP changes you made as a WIP snapshot. This updates the index to show your WIP files as uncommitted.

https://www.kernel.org/pub/software/scm/git/docs/git-reset.html

Obviously, this is normal, but it seems that these two teams can be replaced by

 $ git reset HEAD^ 

(which is equivalent)

 $ git reset --mixed HEAD^ 

which should reset both the HEAD pointer and the index to the previous commit. Is there a difference between the result of this command and the previous two? If not, is there any reason to prefer a two-step process? Or is it just done in documents to explicitly illustrate the behavior of -soft?

Answer 1

No, it seems there is no difference.
This is illustrated more by git reset --soft (i.e. only moving HEAD, which can use other more practical applications )

git reset HEAD is for "uninstallation", and a simple git reset HEAD^ performs both actions (moving HEAD and unsteadiness, without the need for --mixed , as this is the default option)

---

Here is a quick test to see how it looks:

Before (you just go back to the function where you did the “ wip ” - work in progress):

 C:\Users\VonC\prog\git\test\r\r3>gl * 6ac95bd - (origin/master, origin/HEAD, master) fix in master (2 minutes ago) <VonC> | * fd8d97d - (HEAD, origin/feature, feature) snap WIP (3 minutes ago) <VonC> | * 16066dd - f1 (3 minutes ago) <VonC> |/ * e8ad96f - f1 (3 minutes ago) <VonC> 

Self reset:

 C:\Users\VonC\prog\git\test\r\r3>git reset "HEAD^" Unstaged changes after reset: M f 

This gives you the status:

 C:\Users\VonC\prog\git\test\r\r3>git st # On branch feature # Your branch is behind 'origin/feature' by 1 commit, and can be fast-forwarded. # (use "git pull" to update your local branch) # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: f # no changes added to commit (use "git add" and/or "git commit -a") 

log after git reset HEAD^

 C:\Users\VonC\prog\git\test\r\r3>gl * 6ac95bd - (origin/master, origin/HEAD, master) fix in master (6 minutes ago) <VonC> | * fd8d97d - (origin/feature) snap WIP (7 minutes ago) <VonC> | * 16066dd - (HEAD, feature) f1 (7 minutes ago) <VonC> |/ * e8ad96f - f1 (8 minutes ago) <VonC> 

---

In two steps, you could see the following log after git reset --soft HEAD^ :

 C:\Users\VonC\prog\git\test\r\r2>gl * 6ac95bd - (origin/master, origin/HEAD, master) fix in master (65 seconds ago) <VonC> | * fd8d97d - (origin/feature) snap WIP (89 seconds ago) <VonC> | * 16066dd - (HEAD, feature) f1 (2 minutes ago) <VonC> |/ * e8ad96f - f1 (2 minutes ago) <VonC> 

Your index will still reflect what was delivered for wip :

 C:\Users\VonC\prog\git\test\r\r2>git st # On branch feature # Your branch is behind 'origin/feature' by 1 commit, and can be fast-forwarded. # (use "git pull" to update your local branch) # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: f # 

reset will then be unsteady, returning you to the same level as git reset HEAD^ , in one step:

 C:\Users\VonC\prog\git\test\r\r2>git reset Unstaged changes after reset: M f C:\Users\VonC\prog\git\test\r\r2>git st # On branch feature # Your branch is behind 'origin/feature' by 1 commit, and can be fast-forwarded. # (use "git pull" to update your local branch) # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: f # no changes added to commit (use "git add" and/or "git commit -a")