thinking about git reset today and I'm wondering why we usually use `git reset` instead of `git branch --force` to force a branch to point at a different commit
I guess it's mostly more ergonomic? (because you can't use `git branch -f` if you have the branch you want to change checked out)
`git branch` kind of feels like a more natural home for that functionality though, and the `--force` makes it more clear that it's potentially a dangerous action
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.
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.
