Git command - significance of "-" and "--"

Question

When learning git, I'm getting confused with when to use a single dash and double dash. What is the significant difference in the usage?

git ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]] <tree-ish> [<path>…]

Sometimes i can use these interchangeably . ex: -l and --long which confuses me more.

Answer 1

Git is close to the POSIX Utility Argument Syntax but uses --arg=xx as well (GNU)

This document "Standards for Command Line Interfaces" resumes well the convention used:

In the original Unix tradition, command-line options are single letters preceded by a single hyphen.
Mode-flag options that do not take following arguments can be ganged together; thus, if -a and -b are mode options, -ab or -ba is also correct and enables both.
The argument to an option, if any, follows it (optionally separated by whitespace).
In this style, lowercase options are preferred to uppercase. When you use uppercase options, it's good form for them to be special variants of the lowercase option.

The original Unix style evolved on slow ASR-33 teletypes that made terseness a virtue; thus the single-letter options.
Holding down the shift key required actual effort; thus the preference for lower case, and the use of “-” (rather than the perhaps more logical “+”) to enable options.

The GNU style uses option keywords (rather than keyword letters) preceded by two hyphens. It evolved years later when some of the rather elaborate GNU utilities began to run out of single-letter option keys (this constituted a patch for the symptom, not a cure for the underlying disease).
It remains popular because GNU options are easier to read than the alphabet soup of older styles.
GNU-style options cannot be ganged together without separating whitespace. An option argument (if any) can be separated by either whitespace or a single “=” (equal sign) character.

The GNU double-hyphen option leader was chosen so that traditional single-letter options and GNU-style keyword options could be unambiguously mixed on the same command line.
Thus, if your initial design has few and simple options, you can use the Unix style without worrying about causing an incompatible ‘flag day’ if you need to switch to GNU style later on.
On the other hand, if you are using the GNU style, it is good practice to support single-letter equivalents for at least the most common options.