4 ms·

I really agree with this, it's too late for git now, but I consider the overloading of 'checkout' to be one of the worst pieces of UI I've ever come across, and

I really agree with this, it's too late for git now, but I consider the overloading of 'checkout' to be one of the worst pieces of UI I've ever come across, and the source of confusion for many people when I try to teach them git. I didn't know that 'git reset' has a similar problem. If git gained the 'checkout-tree' and 'checkout-file' (and other) commands mentioned, I'd personally use them instead of checkout.

sametmax 9y ago
Yeah as a trainer those are my pet peeve as well. And of course hard vs soft reset and so many ways to undo work. Those 2 commands would be a great idea.
CmdrKrool 9y ago
This is my go to page for untangling the behaviour of git reset and checkout: https://git-scm.com/blog/2011/07/11/reset.html https://git-scm.com/blog/2011/07/11/reset.html . And I find myself going to it quite often because another problem with this kind of slippery design is it just doesn't stick, in your head. (Amusingly, the author begins by admitting he wrote a whole book on Git - and perhaps the most popular one - before strongly understanding this himself.)
ajarmst 9y ago
It's not really too late for git, if there is sufficient energy around rolling back the change. The relatively standard process for API changes of (1) adding a new command that does the same thing for a major version, (2) adding a deprecation warning and description of the new way to do it (say 'Please use checkout-tree instead') for another major version or two before (3) it stops working in major version 3. That allows people to get used to a syntax change without breaking scripts for a while. The git project has already used that process for other API changes. In fact, it's pretty common practice to do that sort of thing when a given CLI option starts getting too baroque and complex.
stephengillie 9y ago
Git is really 2 tools in 1: a manual Distributed File System, and a Version Control System built on hashing. And much new vocabulary. Instead of helping to make the system simpler and easier to understand, the vocabulary actually makes the system more complex and increases the slope of the learning curve. It shouldn't be so complex to indicate you've copied files from Github, made a personal copy to work on, and have switched to that copy. But this involves finding where your Head is, having an Origin, a Master, and somewhere Remote, finding the right branch in the tree to hit with a fork, and going to a checkout counter.
SilasX 9y ago
Agreed. When reading this I realized how I avoid the path-usages of checkout, specifically because it breaks the whole checkout model. The only exceptions is `git checkout -- .` (which I treat like a separate command that happens to use the same words).
- kiallmacinnes 9y ago
  Okay, now I'm curious, what does `git checkout -- .` do? I consider myself fairly good with Git, having used many (but nowhere near all) of it's more advanced features, some of them regularly - but this is a new one to me. The double dash typically indicates all CLI flags/options have been provided, and the remainder should be treated as positional arguments. However, a single . isn't any standard CLI flag, so shouldn't need the --? What am I missing? :)
  - SilasX 9y ago
    Argh -- good catch. You're right, `git checkout .` does the same thing as `git checkout -- .` (discard unstaged changes), and I'd been using the latter for a while before I realized, so I usually use the longer one out of habit.
    - kiallmacinnes 9y ago
      Hey, it happens! I'm confident some of the flags I provide git daily do nothing meaningful either ;) Edit: I also googled it, as I thought up a reason why -- might be used. If I have a file called master, and want to unstage my changes to it, I would have to `git checkout master`. Given this command has multiple meanings, both of which could be appropriate, I'd need to disambiguate between them. The -- does exactly this, it prevents the tree-ish parsing.

sametmax 9y ago

Yeah as a trainer those are my pet peeve as well. And of course hard vs soft reset and so many ways to undo work. Those 2 commands would be a great idea.

CmdrKrool 9y ago

This is my go to page for untangling the behaviour of git reset and checkout: https://git-scm.com/blog/2011/07/11/reset.html https://git-scm.com/blog/2011/07/11/reset.html . And I find myself going to it quite often because another problem with this kind of slippery design is it just doesn't stick, in your head. (Amusingly, the author begins by admitting he wrote a whole book on Git - and perhaps the most popular one - before strongly understanding this himself.)

ajarmst 9y ago

It's not really too late for git, if there is sufficient energy around rolling back the change. The relatively standard process for API changes of (1) adding a new command that does the same thing for a major version, (2) adding a deprecation warning and description of the new way to do it (say 'Please use checkout-tree instead') for another major version or two before (3) it stops working in major version 3. That allows people to get used to a syntax change without breaking scripts for a while. The git project has already used that process for other API changes. In fact, it's pretty common practice to do that sort of thing when a given CLI option starts getting too baroque and complex.

stephengillie 9y ago

Git is really 2 tools in 1: a manual Distributed File System, and a Version Control System built on hashing. And much new vocabulary. Instead of helping to make the system simpler and easier to understand, the vocabulary actually makes the system more complex and increases the slope of the learning curve. It shouldn't be so complex to indicate you've copied files from Github, made a personal copy to work on, and have switched to that copy. But this involves finding where your Head is, having an Origin, a Master, and somewhere Remote, finding the right branch in the tree to hit with a fork, and going to a checkout counter.

SilasX 9y ago

Agreed. When reading this I realized how I avoid the path-usages of checkout, specifically because it breaks the whole checkout model. The only exceptions is `git checkout -- .` (which I treat like a separate command that happens to use the same words).

kiallmacinnes 9y ago
Okay, now I'm curious, what does `git checkout -- .` do? I consider myself fairly good with Git, having used many (but nowhere near all) of it's more advanced features, some of them regularly - but this is a new one to me. The double dash typically indicates all CLI flags/options have been provided, and the remainder should be treated as positional arguments. However, a single . isn't any standard CLI flag, so shouldn't need the --? What am I missing? :)
- SilasX 9y ago
  Argh -- good catch. You're right, `git checkout .` does the same thing as `git checkout -- .` (discard unstaged changes), and I'd been using the latter for a while before I realized, so I usually use the longer one out of habit.
  - kiallmacinnes 9y ago
    Hey, it happens! I'm confident some of the flags I provide git daily do nothing meaningful either ;) Edit: I also googled it, as I thought up a reason why -- might be used. If I have a file called master, and want to unstage my changes to it, I would have to `git checkout master`. Given this command has multiple meanings, both of which could be appropriate, I'd need to disambiguate between them. The -- does exactly this, it prevents the tree-ish parsing.