0

Both seem to add everything in the current directory. The Git add documentation points to pathspec, which points to fnmatch(3).

The docs suggests that git add . will add everything in the current directory, while git add * will add everything that matches *, which happens to be everything in the current directory. This then should result in the same outcome right? Perhaps git add . is a bit more performant because we don't have to expand the glob first?

neverendingqs
  • 4,006
  • 3
  • 29
  • 57
  • 3
    Does this answer your question? [git add \* (asterisk) vs git add . (period)](https://stackoverflow.com/questions/26042390/git-add-asterisk-vs-git-add-period) – EncryptedWatermelon Dec 04 '19 at 16:34
  • 1
    It possibly helps to reiterate that when you run `git add *` (on a Unix-like system, Mac OS X included), _the shell_ expands the `*` and the `git` programs receives the string "add" as its first argument and the names of the files produced by the shell as the rest of the arguments. The dot, `.` is passed to `git add` literally, and handled by `git add` by itself. The fact `*` as implemented by commonly used shells does not match the so-called "dot files" is actually a "usability hack" from the olden days, and it [can be configured](https://superuser.com/a/373751/130459). – kostix Dec 04 '19 at 19:03

1 Answers1

4

This then should result in the same outcome right?

Not exactly

Since * does not match hidden files in the shell, git add * will not add the hidden files/dirs in the current directory (but hidden files in subdirs will match since you add the full dir).

git add . will add everything, including hidden files in current dir.

Simple POC to illustrate:

$ tree -a
.
├── blah
├── .hidden
└── some
    ├── dir
    │   ├── .hidden
    │   └── titi
    ├── .hidden
    └── tata

2 directories, 6 files

$ git init
Initialized empty Git repository in /mydir/.git/

$ git add *

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   blah
    new file:   some/.hidden
    new file:   some/dir/.hidden
    new file:   some/dir/titi
    new file:   some/tata

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    .hidden

$ git add .

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   .hidden
    new file:   blah
    new file:   some/.hidden
    new file:   some/dir/.hidden
    new file:   some/dir/titi
    new file:   some/tata
Zeitounator
  • 38,476
  • 7
  • 53
  • 66
  • I'll be glad to know in which way this does not answer the OP's question. – Zeitounator Dec 04 '19 at 16:41
  • Don't know why the negative votes. Adding hidden files sounds like a big difference to me... just consider .gitignore, .gitattributes.... that's a _big_ difference in outcome. – eftshift0 Dec 04 '19 at 16:42
  • 1
    Not sure why the downvotes, but note that some command-line interpreters (the old CMD one on Windows, notoriously) don't expand `*` themselves. In this case it's up to Git to do it. – torek Dec 04 '19 at 18:24