Difference in the paths in .gitignore file?

Question

I've been using git but still having confusion about the .gitignore file paths.

So, what is the difference between the following two paths in .gitignore file?

 tmp/* public/documents/**/* 

I can understand that tmp/* will ignore all the files and folders inside it. Am I right? But what does that second line path mean?

Answer 1

This depends on the behavior of your shell. Git doesn't do any work to determine how to expand these. In general, * matches any single file or folder:

/a/*/z  matches        /a/b/z  matches        /a/c/z  doesn't match  /a/b/c/z 

** matches any string of folders:

/a/**/z  matches        /a/b/z  matches        /a/b/c/z  matches        /a/b/c/d/e/f/g/h/i/z  doesn't match  /a/b/c/z/d.pr0n 

Combine ** with * to match files in an entire folder tree:

/a/**/z/*.pr0n  matches        /a/b/c/z/d.pr0n  matches        /a/b/z/foo.pr0n  doesn't match  /a/b/z/bar.txt 

Answer 2

Update (08-Mar-2016)

Today, I am unable to find a machine where ** does not work as claimed. That includes OSX-10.11.3 (El Capitan) and Ubuntu-14.04.1 (Trusty). Possibly git-ignore as been updated, or possibly recent fnmatch handles ** as people expect. So the accepted answer now seems to be correct in practice.

---

Original post

The ** has no special meaning in git. It is a feature of bash >= 4.0, via

shopt -s globstar

But git does not use bash. To see what git actually does, you can experiment with git add -nv and files in several levels of sub-directories.

For the OP, I've tried every combination I can think of for the .gitignore file, and nothing works any better than this:

public/documents/

The following does not do what everyone seems to think:

public/documents/**/*.obj

I cannot get that to work no matter what I try, but at least that is consistent with the git docs. I suspect that when people add that to .gitignore, it works by accident, only because their .obj files are precisely one sub-directory deep. They probably copied the double-asterisk from a bash script. But perhaps there are systems where fnmatch(3) can handle the double-asterisk as bash can.