7 ms·

The checkout command is severely overloaded; I'd hardly remember the functions if it wasn't for aliases. The reset operations are also very inconvenient, due t

The checkout command is severely overloaded; I'd hardly remember the functions if it wasn't for aliases. The reset operations are also very inconvenient, due to the mix of: different types of reset (soft/hard); overlapping with the checkout command; different states of the files. Pushing is also overloaded, due to handling both branches and tags (this is probably due to the fact that both have refs). There are strange warts (e.g. adding with --patch doesn't include files not in the index; displaying the content a given stash entry requires typing the whole - unnecessarily complex - entry name), which I don't doubt make sense technically, but from a user perspective, they're odd. There's probably a lot of stuff that one can find, depending on how wide their usage is. For example, I actually didn't realize how convenient patched (--patch) unstaging would be, since I typically perform a reset, then add (--patch) again. I've personally never got past the feeeling that, not frequently but still with some frequence, git operations have a byzantine UX. edit: find the merge commit of a given commit is something also very missed; it requires a non-trivial alias.

madeofpalk 4y ago
> The checkout command is severely overloaded I guess that's why they split git checkout into git switch and git restore
bryanrasmussen 4y ago
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.
- anonymous_sorry 4y ago
  > if instead of checkout you had a bunch of separate functions you think you would remember those? It does (switch/restore) and I do.
- afiori 4y ago
  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.
- vvillena 4y ago
  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.
anonymous_sorry 4y ago
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!
- b0afc375b5 4y ago
  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.
  - jawilson2 4y ago
    I've been using git since 2009, first for me too
  - jacobyoder 4y ago
    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.
andreareina 4y ago
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).
- pizza234 4y ago
  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!
_huayra_ 4y ago
> 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 https://stackoverflow.com/a/34260242/2492058
- ecnahc515 4y ago
  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.
  - _huayra_ 4y ago
    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 :(

madeofpalk 4y ago

> The checkout command is severely overloaded I guess that's why they split git checkout into git switch and git restore

bryanrasmussen 4y ago

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.

anonymous_sorry 4y ago
> if instead of checkout you had a bunch of separate functions you think you would remember those? It does (switch/restore) and I do.
afiori 4y ago
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.
vvillena 4y ago
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.

anonymous_sorry 4y ago

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!

b0afc375b5 4y ago
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.
- jawilson2 4y ago
  I've been using git since 2009, first for me too
- jacobyoder 4y ago
  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.

andreareina 4y ago

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

pizza234 4y ago
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!

_huayra_ 4y ago

> 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 https://stackoverflow.com/a/34260242/2492058

ecnahc515 4y ago
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.
- _huayra_ 4y ago
  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 :(