I've noticed that if I try to git reset on a secondary worktree, it resets based on the primary worktree.
Suppose I have master (d) checked out on my normal repo, and have feature (f) in my separate worktree. If I do git reset --hard head~1 I end up at c rather than e as I would expect:
master _______a______c__d
feature \__b________e__f
I've tried looking for how to correctly reset in a worktree, but have been unable to find anything.
The trick here is that you are on a case-folding system (typical of a MacOS or Windows setup, but not for Linux setups) and you used head (lowercase) instead of HEAD (all uppercase).
When you do this in the main work-tree of a repository, it works anyway. But when you do this in an added work-tree, it fails: head resolves to the tip commit of the branch in the main work-tree, rather than the tip of the branch in your current work-tree. For instance, if you are in a work-tree working on feature while the main work-tree has master checked out, HEAD~1 means feature~1 but head~1 means master~1.
If you don't like typing out HEAD in all uppercase, you can use the @ symbol where you would have used HEAD. For instance, @~1 means the same thing as HEAD~1; git reset --hard @ means the same thing as git reset --hard; and so on.