How do I reset the working tree without moving HEAD?

Question

Given a git branch with some commits on it (C is the most recent commit):

A -> B -> C

How do I reset my workspace so that all the files are in the state they were at commit B, but HEAD is still at C?

I've looked at git-reset, but none of the options seem to help. The man page suggests that all the different modes will move HEAD:

--soft
   Does not touch the index file or the working tree at all 
   (but resets the head to <commit>, just like all modes do).

I've tried git reset HEAD~ but that moves HEAD.

You haven't been selecting answers to many of your questions lately. Any particular reason for that? — Mad Physicist, Oct 18 '16 at 13:25
Oh, sorry about that. Most of them have good answers, so I'll sort it out. — Wilfred Hughes, Oct 19 '16 at 00:29

xaizek · Accepted Answer · 2016-10-17T20:58:36.740

20

git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...

git checkout with <paths> or --patch is used to restore modified or deleted paths to their original contents from the index or replace paths with the contents from a named <tree-ish> (most often a commit-ish).

So you need to run this at root of your repository (works fine for any sub-tree or file(s) too):

git checkout HEAD~ -- .

This will result in git applying changes necessary to revert files to HEAD~ state, the changes will be in the index.

edited Oct 17 '16 at 20:58

answered Oct 17 '16 at 20:45

xaizek

5,098
1
34
60

1

In case it's not obvious, if you want to go back to a different SHA you can replace `HEAD~`, i.e. `git checkout A -- .` – Carl Walsh Oct 22 '20 at 21:29
This doesn't remove files that were added since HEAD~ – Pod Jan 12 '21 at 10:48
@Pod, correct. `git clean` can remove untracked files, but be careful with it, it can remove files you want to keep. – xaizek Jan 12 '21 at 11:45

Mad Physicist · Answer 2 · 2016-10-17T20:52:20.507

11

You could use a combination of hard and soft resets:

git reset --hard B
git reset --soft C

The first would move HEAD to B and make all your files look like B. The second would then move it back to C without changing any files.

This method has the advantage that you are not in a detached-head state and all the differences between B and C will just show up as inverse diffs of your last actual commit. You will still be on your original branch.

You would probably have to specify C as a SHA-1 rather than a ref name, unless you specifically created one for the purpose.

edited Oct 17 '16 at 20:52

answered Oct 17 '16 at 20:44

Mad Physicist

107,652
25
181
264

4

`HEAD@{1}` should do for `C` instead of a hash. – CherryDT Feb 23 '18 at 21:23
1

Much more explicit than tricky punctuation in accepted answer. – hans Feb 12 '19 at 16:10
@DylanYoung `HEAD~ -- .` is somewhat harder to read and copy correctly than `HEAD@{1}` – Mad Physicist Apr 15 '20 at 19:24
This is very clever, and much easier to understand than the accepted answer – kylebebak Aug 31 '21 at 22:40
@kylebebak. Thanks. I prefer it to the accepted answer myself. – Mad Physicist Aug 31 '21 at 22:40

score 1 · Answer 3 · answered Aug 10 '23 at 10:09

As pointed out in this answer to a similar question, you can use git restore for that in Git 2.23+, like so:

git restore -s HEAD~ .

According to its manpage, git restore

[restores] specified paths in the working tree with some contents from a restore source.

You use -s (or --source) to specify which commit you want to use as the restore source (here HEAD~) and specify the path(s) to restore (here everything, so .) at the end.

score -1 · Answer 4 · edited Oct 17 '16 at 20:46

-1

Just use git checkout:

$ git checkout HEAD~
$ # Or
$ git checkout HEAD^
$ # Or
$ git checkout B

This will bring you into a detached head state where the HEAD is detached from a branch.

edited Oct 17 '16 at 20:46

Mad Physicist

107,652
25
181
264

answered Oct 17 '16 at 20:44

das_j

4,444
5
31
47

Triple ticks don't work on SO unfortunately. Indent by four spaces manually or highlight and click on the `{}` button in the editing toolbar. – Mad Physicist Oct 17 '16 at 20:47
@MadPhysicist Damn it, I'm used to this from github, but thank you! – das_j Oct 17 '16 at 20:47
No worries. I had the other problem where I kept dreading the manual indentation in GitHub until I figured out the triple ticks. – Mad Physicist Oct 17 '16 at 20:48
6

I don't want to change HEAD I'm afraid. – Wilfred Hughes Oct 17 '16 at 21:38
@WilfredHughes The HEAD or the master branch? – das_j Oct 17 '16 at 22:04
He doesn't want to change the HEAD symbolic ref. He wants the changes from another commit to be present in the working tree, presumably so he can recover that work (e.g. after a tricky rebase). – DylanYoung Apr 15 '20 at 18:56

How do I reset the working tree without moving HEAD?

4 Answers4

Linked

Related