4 ms·

The git CLI is a mess. It's inconsistent even within its own commands. For example, sometimes specifying remote and branch is done as "remote/branch" and some

by NateDad 12y ago

The git CLI is a mess. It's inconsistent even within its own commands. For example, sometimes specifying remote and branch is done as "remote/branch" and sometimes as "remote branch". It even uses different words for the same thing - sometimes remove, sometimes rm sometimes -d. Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch". The reason people don't use other git frontends is that a vast majority of the help topics already out there only reference git itself. So if you want help for rebase, for example, if you're using some frontend that re-kajiggers the command line, all that help is now useless, or even worse, potentially downright incorrect.

nhaehnle 12y ago
> For example, sometimes specifying remote and branch is done as "remote/branch" and sometimes as "remote branch". AFAIK those usages are semantically different, and consistently so. For example, git pull actually is "repository ref" rather than "remote ref", and will go over the network to fetch the current status of ref from the given repository. git merge, on the other hand, is simply "git merge ref"; when ref is of the form remote/branch, it will merge the current local state of remote/branch, which should be the state from the last git fetch. git merge does not access the network. So: semantic differences, represented via different command line syntaxes. It's actually pretty reasonable, and it's pretty obvious if you've taken half an hour to understand the underlying data model of Git. > Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch". Actually, "git branch" is the command to create a new branch. "git checkout -b" is a shortcut for "create a new branch and move to that branch".
- NateDad 12y ago
  > those usages are semantically different, and consistently so They're very close to the same syntax, and the fact that they're significantly different just shows again that the CLI is a mess. If they're so different, they should have significantly different syntax. "space versus slash" is not significantly different. I'm sure I'm not the first person to create a new branch called "upstream/master" :P The problem with git branch versus git checkout -b is that 99% of the time, what people want to do is create a branch and switch to it. The "create a branch and don't switch to it" could just be a flag on git branch. It DEFINITELY should not be two completely different commands. > it's pretty obvious if you've taken half an hour to understand the underlying data model of Git This is the biggest red flag about git's CLI. I shouldn't need to know the implementation to use the UI.
  - mnem 12y ago
    I have a good grasp of git CLI but bugger all understanding of it's internals, so you certainly don't need to know. It seems fairly likely that what is considered a reasonable interface or a bad interface has a high level of subjectivity. Why bother getting bogged down with such debate? If you dislike git, use something else. If git is forced upon you, write some simple wrappers which provide the interface you want for your top few most used operations, or ask for help to do so from the people forcing you to use it. Or just hang around hacker news and complain without anything changing. It's certainly my favourite method of avoiding work :)
    - NotSammyHagar 12y ago
      I can't understand why they haven't tried to fix their CLI syntax. Besides having to remember when to do origin <space> branch and origin/branch, there is also how do you set the upstream branch, there's a couple of ways there. And then creating a branch and switching to it. Is it 'git branch -c foobar' or 'git checkout -c foobar'. Was it -c for create? why not allow it on both? And its so easy to fix these things.
  - spb 12y ago
    > This is the biggest red flag about git's CLI. I shouldn't need to know the implementation to use the UI. This speaks to a fundamental misunderstanding of the nature of Git. You need to know the model of anything to be able to use it properly- you've mixed up Git's model with its "implementation" (probably because Git's model is so lightweight and exposes a lot of its fundamental workings, [as is right for proper usability][1]). This is like saying you shouldn't have to know what files and folders are to open a document in Word, Yes, you should. [1]: http://en.wikipedia.org/wiki/Seven_stages_of_action#Usage_as_Design_Aids http://en.wikipedia.org/wiki/Seven_stages_of_action#Usage_as...

by NateDad 12y ago

nhaehnle 12y ago

> For example, sometimes specifying remote and branch is done as "remote/branch" and sometimes as "remote branch". AFAIK those usages are semantically different, and consistently so. For example, git pull actually is "repository ref" rather than "remote ref", and will go over the network to fetch the current status of ref from the given repository. git merge, on the other hand, is simply "git merge ref"; when ref is of the form remote/branch, it will merge the current local state of remote/branch, which should be the state from the last git fetch. git merge does not access the network. So: semantic differences, represented via different command line syntaxes. It's actually pretty reasonable, and it's pretty obvious if you've taken half an hour to understand the underlying data model of Git. > Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch". Actually, "git branch" is the command to create a new branch. "git checkout -b" is a shortcut for "create a new branch and move to that branch".

NateDad 12y ago
> those usages are semantically different, and consistently so They're very close to the same syntax, and the fact that they're significantly different just shows again that the CLI is a mess. If they're so different, they should have significantly different syntax. "space versus slash" is not significantly different. I'm sure I'm not the first person to create a new branch called "upstream/master" :P The problem with git branch versus git checkout -b is that 99% of the time, what people want to do is create a branch and switch to it. The "create a branch and don't switch to it" could just be a flag on git branch. It DEFINITELY should not be two completely different commands. > it's pretty obvious if you've taken half an hour to understand the underlying data model of Git This is the biggest red flag about git's CLI. I shouldn't need to know the implementation to use the UI.
- mnem 12y ago
  I have a good grasp of git CLI but bugger all understanding of it's internals, so you certainly don't need to know. It seems fairly likely that what is considered a reasonable interface or a bad interface has a high level of subjectivity. Why bother getting bogged down with such debate? If you dislike git, use something else. If git is forced upon you, write some simple wrappers which provide the interface you want for your top few most used operations, or ask for help to do so from the people forcing you to use it. Or just hang around hacker news and complain without anything changing. It's certainly my favourite method of avoiding work :)
  - NotSammyHagar 12y ago
    I can't understand why they haven't tried to fix their CLI syntax. Besides having to remember when to do origin <space> branch and origin/branch, there is also how do you set the upstream branch, there's a couple of ways there. And then creating a branch and switching to it. Is it 'git branch -c foobar' or 'git checkout -c foobar'. Was it -c for create? why not allow it on both? And its so easy to fix these things.
- spb 12y ago
  > This is the biggest red flag about git's CLI. I shouldn't need to know the implementation to use the UI. This speaks to a fundamental misunderstanding of the nature of Git. You need to know the model of anything to be able to use it properly- you've mixed up Git's model with its "implementation" (probably because Git's model is so lightweight and exposes a lot of its fundamental workings, [as is right for proper usability][1]). This is like saying you shouldn't have to know what files and folders are to open a document in Word, Yes, you should. [1]: http://en.wikipedia.org/wiki/Seven_stages_of_action#Usage_as_Design_Aids http://en.wikipedia.org/wiki/Seven_stages_of_action#Usage_as...