My understanding is that git follows the 'standard' Linux convention for flags. That is:
- one dash for 'short' flags: generally one character flags, but sometimes flags with a single character, then further characters which represent a parameter to the flag (e.g.
git log -SFoo
, in which Foo
is a parameter to the -S
flag). These flags may or may not be abbreviated forms of other, longer flags.
- Two dashes for 'long' flags: multi-character flags which are usually an English word. If these flags receive parameters, it is separated from the flag by an
=
sign (e.g. git log --author=Peter
).
This is the 'why': it is a convention which is embedded in the Linux world. Git comes from this world, so it follows the convention. The 'two dashes for a long flag, one for a short flag' rule should guide you as to how many dashes to use for a flag.
As for why there are duplicate short and long flags, such as --quiet
and -q
, it's just to provide the option of either mnemonic convenience or terseness. --quiet
is easier to remember, but -q
is quicker to type and mentally parse if you're used to it. For instance, I type git commit -m "...blah"
so frequently it would get on my nerves if I had to double the length of my command every time by entering git commit --message='...blah'
.
I haven't come across any git flags which behave differently given two dashes and one dash, so generally if you enter two dashes for a one-dash flag or vice versa, nothing irreparably bad will happen, git will just complain about your flags and do nothing.
Of course, git has a vast number of commands, each with a vast number of flags, so it is possible that there are exceptions to all these rules. They should generally hold though.