[Someone]

> The UI of git - for better or worse - directly reflects its internals.

I disagree. For example, we have, from “git checkout —help”:

   git checkout has two main modes:

   1. Switch branches, with git checkout <branch>

   2. Restore a different version of a file

The first variant never loses changes you made that aren’t in git yet, the second is explicitly designed to revert them. How does that directly reflects git internals?

(And of course, there are many inconsistencies in the CLI that do not have to do with git internals that, even if you know what you want to do internally and which command to use, make figuring out the CLI incantation to do it harder than needed. That’s a different subject, but still contributes to “git is difficult to use”)

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

[inigyou]

I think they tried to fix this by adding new separate commands, right? git restore?

[WorldMaker]

Yes, `git switch` and `git restore` are both marked stable now and have relatively clean UX. It can be worth reskilling out of `git checkout` habits and into these two separate commands.