How do I hard reset a worktree to origin with git?

Question

I am experiencing with git worktrees. I created a bare clone and create my worktrees form it. I created a branch in a separate worktree, worked on it, and pushed it. Then I made a local commit that I would like to remove, so I ran git reset --hard origin/mybranch but as a result I get the following error message:

fatal: ambiguous argument 'origin': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

If I remove and recreate the worktree then I end up in the same state with the faulty commit still there. If I remove both the worktree and the branch (with git branch -r) and recreate the worktree then I get to the main branch (and not the one I created) with seemingly no way to get the feature branch I created.

How can I revert my worktree to the remote version of my branch ?

---

EDIT: I made a whole test scenario trying some of the suggested answers, you can see my bash session below. I do have a remote named origin. I think the problem mainly comes from the fact that I am using a bare clone (git commit --bare XXX). When using a non-bare repo it works correctly.

~/sources/iced> git clone --bare https://github.com/iced-rs/iced.git iced
# ...
Receiving objects: 100% (31149/31149), 9.85 MiB | 3.54 MiB/s, done.
Resolving deltas: 100% (21892/21892), done.
~/sources/iced> cd iced
~/sources/iced/iced> git worktree add ../0.8 0.8
Preparing worktree (checking out '0.8')
HEAD is now at 0e1a9e65 Merge branch 'master' into 0.8
~/sources/iced/iced> cd ../0.8
~/sources/iced/0.8> git log --pretty=oneline | head
0e1a9e653f79759caa955e87c594bea8606a189c Merge branch 'master' into 0.8
2b8742937fb41fbe2ce60a494bfce2fd8b6ab916 Bump version of `iced_native` :tada:
1b79df44337abf46f9ef3fbd2f46a96da952639d Merge pull request #1717 from iced-rs/remove-clone-image-bytes
~/sources/iced/0.8> nvim
~/sources/iced/0.8> git add . && git commit -m "dummy commit"
[0.8 e8bbb041] dummy commit
 1 file changed, 1 insertion(+), 1 deletion(-)
~/sources/iced/0.8> git log --pretty=oneline | head
e8bbb0414b8a602a54b2363915db24f593621492 dummy commit
0e1a9e653f79759caa955e87c594bea8606a189c Merge branch 'master' into 0.8
2b8742937fb41fbe2ce60a494bfce2fd8b6ab916 Bump version of `iced_native` :tada:
~/sources/iced/0.8> cd ../iced
~/sources/iced/iced> git remote
origin
~/sources/iced/iced> git reset --hard origin/0.8
fatal: ambiguous argument 'origin/0.8': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
~/sources/iced/iced> cd ../0.8
~/sources/iced/0.8> git reset --hard origin/0.8
fatal: ambiguous argument 'origin/0.8': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
~/sources/iced/0.8> cd ../iced
~/sources/iced/iced> git reset --hard '0.8@{upstream}'
fatal: no upstream configured for branch '0.8'
~/sources/iced/iced> cd ../0.8
~/sources/iced/0.8> git reset --hard '0.8@{upstream}'
fatal: no upstream configured for branch '0.8'

Answer 1

Let's take it as a premise of the question that you cannot refer to the desire commit as origin/mybranch (for whatever reason). Well, you know how many "bad" commits there are, so reset back by that number of commits:

git reset --hard @~1 # replace "1" with any desired number

Alternatively, reset to the SHA of the desired commit:

git reset --hard <SHA-of-desired-commit>

Answer 2

Edit: This is wrong and did not take into consideration that worktrees were being used. See Guildenstern's answer and comments for the right answer.

That error seems to indicate that your remote is not named origin. You can check the configured remotes with git remote:

$ git remote
origin2

You could also use @{upstream} or @{u} to get the upstream branch automatically:

$ git reset --hard 'master@{upstream}'

For more information on this syntax, you can check man 7 gitrevisions.

Answer 3

I think the problem mainly comes from the fact that I am using a bare clone

You’re on the right track.

As is often the case with Git, things might be a bit unintuitive. But if you kind of reason your way backwards a few steps (maybe five) it might begin to make sense.

From man git clone:

Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/. When this option is used, neither remote-tracking branches nor the related configuration variables are created.

You don’t have any remote-tracking branches. So origin/<branch> doesn’t exist. You just have your branches (also known as refs/heads/*) and that’s it. When you cloned the repository, the branches on the remote were mapped directly to your branches (instead of only creating corresponding origin/* refs except for the default branch).

And that (going back to reasoning backwards) kind of makes sense: remote-tracking branches are useful when you’re developing things since you can compare your own state with the remote. But you don’t have a working tree in a bare repository (see next section) so you can’t develop anything. And there is no “remote” to compare yourself to. You (the repository) kind of are the remote. Or one of them.

Bare repositories and worktrees

Bare repositories don’t have worktrees per definition. Or at least that’s what man gitglossary says. Of course what git worktree allows you to do trumps that. But it might be ill-defined.