Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Please forgive me if this seems easy, but I only started learning Unix 2 days ago.

Basically, I have been taught that when typing a command into the terminal it needs to be of the form:

[command name][space][-options][space][arguments]

Now I've just started looking at using git, and I've come across the following:

git config --global core.editor "notepad.exe -wl1"

So in this case is git config the command? How can that work when there is a space in the middle of it? Wouldn't unix get confused and think that config would be an option?

Also just to confuse matters even more, very often I see a command called git-config. Is this the same as git config?

I find it really confusing that in something where precise syntax is very important, these things aren't clearly explained.

share|improve this question
add comment

2 Answers

up vote 5 down vote accepted

It is a good starting point, but "generally" needs to be emphasized. For utility commands it is always a good idea to read the man utility page for what is correct syntax.

There is a guideline at The Open Group that can be worth a read. However there is varying level of how conforming implementations are. Some implementations allow one to break this convention, but one should try to heed it as it is both safer and usually more portable (for the day you are on another system with a different implementation.)


When you look at git and quite a few other tools that is not part of the standard utility package one has to learn the way it is done. The use of command is not unique to git but also found in others like pactl / pacmd, amixer etc. As pointed out by @mouviciel this command-based design of git is used by most SCM tools, starting with the old sccs.

program [options] [command] [arguments]

Here often options are geared towards the program itself, and arguments towards the command.

It is a nice way to divide an extended a subset for a main program/suite/tool-kit working within a domain.

domain -verbose DO_THIS -with_file filename.txt
domain -verbose DO_THAT -with_file filename.txt

For some it is also given as a short option and by that adhere to the guidelines like e.g. fdisk -l <device>Enter vs. fdisk <device>Enter, lEnter.


When you execute e.g. git config ... it is not the shell, but git itself that interpret that config is the command. The use of git-config is more a short way of specifying config as a git command. Try e.g. man git-config. By itself it is usually not recognized as a command.


For git this is also a bit more complex. As it is a tool-kit -> suite, as in many, many commands belonging to git – it is natural to use a command based implementation. This is a design chosen by the developers of git itself.

git DO_THIS

Further. As it holds a lot of commands, they have divided the commands in several groups where the two main is classified as Plumbing and Porcelain. Also see: What does the term porcelain mean in Git?. The manual page has a ordered grouping starting from GIT COMMANDS.

Further one can also customize, trough configuration files, what some of the commands do. As an example. You can view differences between commits by git diff. This command can be customized in your .gitconfig. You can specify which diff program to use and how it should be called.


To make help for various commands easily accessible one also has the possibility to say:

git help command

so git help commit, gives you help for git's commit command.


Guess it could help if you see git as a command line suite, or even a menu driven command environment. As with a GUI application where you can click File->Open->[Some file], a command driven suite could have suite open <file>.

share|improve this answer
    
Actually this command-based design of git is used by most SCM tools, starting with the old sccs. –  mouviciel May 23 '13 at 9:23
    
@mouviciel: Yes. Reading over it I'm not to satisfied with all the phrasings. Thanks for comment. Added it. –  Sukminder May 23 '13 at 12:02
add comment

git is the command. It "multiplexes" to the various other git-* commands based on what the first argument is, e.g. git config ... runs git-config.

share|improve this answer
    
Thanks for the answer, but I find that really confusing. Is there an advantage to doing it this way, as apposed to just running git-config in the first place? –  Lars May 19 '13 at 23:50
    
@Lars readability –  Ulrich Dangel May 19 '13 at 23:56
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.