Browse Source

gitcli: contrast wildcard given to shell and to git

People who are not used to working with shell may intellectually
understand how the command line argument is massaged by the shell
but still have a hard time visualizing the difference between
letting the shell expand fileglobs and having Git see the fileglob
to use as a pathspec.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
maint
Junio C Hamano 12 years ago
parent
commit
8300016e0a
  1. 17
      Documentation/gitcli.txt

17
Documentation/gitcli.txt

@ -42,6 +42,23 @@ When writing a script that is expected to handle random user-input, it is @@ -42,6 +42,23 @@ When writing a script that is expected to handle random user-input, it is
a good practice to make it explicit which arguments are which by placing
disambiguating `--` at appropriate places.

* Many commands allow wildcards in paths, but you need to protect
them from getting globbed by the shell. These two mean different
things:
+
--------------------------------
$ git checkout -- *.c
$ git checkout -- \*.c
--------------------------------
+
The former lets your shell expand the fileglob, and you are asking
the dot-C files in your working tree to be overwritten with the version
in the index. The latter passes the `*.c` to Git, and you are asking
the paths in the index that match the pattern to be checked out to your
working tree. After running `git add hello.c; rm hello.c`, you will _not_
see `hello.c` in your working tree with the former, but with the latter
you will.

Here are the rules regarding the "flags" that you should follow when you are
scripting git:


Loading…
Cancel
Save