Skip to content

Commit 8300016

Browse files
committed
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 <[email protected]>
1 parent 008566e commit 8300016

File tree

1 file changed

+17
-0
lines changed

1 file changed

+17
-0
lines changed

Documentation/gitcli.txt

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -42,6 +42,23 @@ When writing a script that is expected to handle random user-input, it is
4242
a good practice to make it explicit which arguments are which by placing
4343
disambiguating `--` at appropriate places.
4444

45+
* Many commands allow wildcards in paths, but you need to protect
46+
them from getting globbed by the shell. These two mean different
47+
things:
48+
+
49+
--------------------------------
50+
$ git checkout -- *.c
51+
$ git checkout -- \*.c
52+
--------------------------------
53+
+
54+
The former lets your shell expand the fileglob, and you are asking
55+
the dot-C files in your working tree to be overwritten with the version
56+
in the index. The latter passes the `*.c` to Git, and you are asking
57+
the paths in the index that match the pattern to be checked out to your
58+
working tree. After running `git add hello.c; rm hello.c`, you will _not_
59+
see `hello.c` in your working tree with the former, but with the latter
60+
you will.
61+
4562
Here are the rules regarding the "flags" that you should follow when you are
4663
scripting git:
4764

0 commit comments

Comments
 (0)