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.
@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.