[dundarious]

Switching branches involves: updating the field marking "current branch", and then updating the working copy to reflect the objects referenced. So for all trees/files, recursively restore wc to match the referenced blobs.

Restoring a different version of a specific file/tree, involves recursively restoring wc of those files/trees to match the referenced blobs.

So both are actually primarily the same task. Knowing a little about internals is exactly how it is easy to understand how the same code (and hence the verb "checkout") came to be used for both tasks.

The reason it's still not great UI is that switching branch and restoring file arise in very different circumstances, and I want different guarantees and warnings and confirmations -- so using the same command still only makes sense when thinking very mechanistically.

[Zardoz84]

you can use git switch to change branches

[dundarious]

I know, I use switch and restore now (for the most part). I'm explaining how knowing the internals does help understand the 2 use-cases being originally implemented via 1 command, i.e., checkout. The post I was responding to said the checkout case ran counter to the idea that knowing the internals helps use the commands, when it's actually a pretty standard case where it does help.

[mlrtime]

Everyone learns git checkout <file> real quick after you lose that uncommitted change. I learned the hard way.