I was learning git around the time `switch` and `restore` were introduced to tackle the problem of checkout being overloaded. I started using the new commands and it instantly made more sense and began to click. I very rarely use checkout at all.

Something to be aware of when training junior devs. Do them a favour and learn switch/restore first!

I think this is the first time I've heard of switch and restore. Before I moved to magit I always used git checkout and git reset.

Git switch and git restore were introduced in Git v2.23, way back in August 2019. So... they're not brand new in the last few months, but... like you (and another poster) I'm not aware of them, as I had ... 8-10 years of muscle memory before without them around. I'm actually trying to think back to when I first used git... I don't think I learned about it at all until around 2007 - company I was at had a lot of SVN and a couple of the folks on the team were exploring other options. And... IIRC, around mid-to-late 2008, someone at a local Ruby group demonstrated github. But... I'm not sure I actually started using git 'for real' until 2010 or so.

So... there was 9+ years of learning certain commands/styles and... switch/restore weren't part of that.

And I've mostly switched to GUIs for day to day stuff - the Tower Mac client and sometimes the JetBrains git tools. They might even now be using 'switch' and 'restore' for some basic operations behind the scenes.

I've been using git since 2009, first for me too

> The checkout command is severely overloaded

I guess that's why they split git checkout into git switch and git restore

> The checkout command is severely overloaded;

I've been using git since 2008. I just learned a few weeks ago that I had the opposite understanding of what --theirs and --ours does on git-checkout during a rebase operation. (briefly: --ours is the branch you are rebasing onto, --theirs is the changes from the branch with the changes you are repeatedly cherry-picking into the new branch. see this answer for more detail [0])

I shudder to think how much I've screwed things up over my career as a result...

[0] https://stackoverflow.com/a/34260242/2492058

It kind-of makes sense when you think of rebase as a composite command that does a checkout of the branch/newbase and cherry-picks the commits from previous branch.

Yes, it actually totally makes sense, but the issue is that if one draws the mental picture the wrong way the first time (and is left uncorrected), it's equally easy to draw the mental picture (i.e. of commits "flying around" from one branch to another) in the other direction too. That's what bit me

I don't even know how to check for mistakes here with my current employer (god speed to the code I wrote at my previous jobs). Unlike a merge, a rebase leaves no trace except in the reflog :(

Push makes sense to me actually, branches and tags are both aliases to a particular commit. What makes them different is that the branch pointer gets updated on commit, while the tag pointer is (meant to be) static.

But I do in general agree that the cli leaves much to be desired. I really have to give credit to magit for making a git ui that is simultaneously easy to use, powerful, and has actually made me more proficient at using the regular cli (the commands that underlie the operations are echoed so whenever I do something new I take a peek at how it's done).

I think there is definitely a technical reason, but I'll explain the UX problem with an example: what does, intuitively, `push --force --tags` do?

1. force push both the branch and the tags

2. force push only the tags

It's very ambiguous - both answers make sense. And that's a big UX problem!

if instead of checkout you had a bunch of separate functions you think you would remember those?

Someone could probably make an argument that commands should be overloaded even more - clone, pull, and checkout could be merged for most of their common operations - as an example. Note: I am not necessarily for this but I'm not necessarily against it either.

agree --patch is weird.

> if instead of checkout you had a bunch of separate functions you think you would remember those?

It does (switch/restore) and I do.

If clone push and pull were overloaded into a

   git sync --from <local or remote ref, or .> --target <local or remote ref, or .>

It would not change much.

The problematic kind of overloading are like how

    git push origin master

and

    git push origin master:master

push master to origin while

    git push origin :master

deletes master from origin.

Check out pacman, the Arch Linux package manager, to see an extreme case of command overloading. It probably makes lots of sense from a conceptual point of view, but for users that simply use a very small subset of the tool, it can get a bit messy.