Using the latter didn't cross my mind previously. I think that I'd usually anyway check out the branch to be moved first (for no good reason) and then `git reset` is more natural, given that it explicitly handles the index and worktree.
I continue to find it weird that git has the reflog, which is a nice universal undo mechanism for lost commits, but none for lost contents of the index or worktree.
@b0rk
BTW re contents of worktree, I've once tried to cobble together something that would "backup" the worktree into a commit without affecting the checked-out branch (so that I can e.g. run it in a build script so that every built binary could point at its exact sources, at least until the repo gets gced). I failed to find a solution that would be racefree and would produce a commit (instead of a naked tree object) -- anything that I could find involved using `commit` and "manually" reverting everything it has done, incl. changes to index, or making a naked tree and trying to make the commit object by hand.