Re: Relative paths don't work in .gitignore as would be expected.

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 2, 2015, 19:15 UTC
Message-ID: <xmqqsieot999.fsf@gitster.dls.corp.google.com>
In-Reply-To: <54CF11CA.6000308@gmail.com>

Stefan Beller <stefanbeller@gmail.com> writes:

Show 12 quoted lines

> On 01.02.2015 14:51, /#!/JoePea wrote:
>> I have this in my .gitignore:
>> 
>>   ./*.js
>> 
>> I would expect that to cause git to ignore .js files in the same
>> folder as .gitignore, but it doesn't do anything. However, this works:
>> 
>>   /*.js
>> 
>> I'm not sure what this actually means because a leading slash is the
>> root of some filesystem,

Isn't gitignore(5) documentation reasonably clear?

 - If the pattern ends with a slash, it is removed for the purpose
   of the following description, but it would only find a match with
   a directory. In other words, foo/ will match a directory foo and
   paths underneath it, but will not match a regular file or a
   symbolic link foo (this is consistent with the way how pathspec
   works in general in Git).

 - If the pattern does not contain a slash /, Git treats it as a
   shell glob pattern and checks for a match against the pathname
   relative to the location of the .gitignore file (relative to the
   toplevel of the work tree if not from a .gitignore file).

 - A leading slash matches the beginning of the pathname. For
   example, "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".

> That's true, though you'd never (barely?) git version control an entire
> file system?

When you have the entire file system under /.git, "/var/" still would be the right way to spell a pattern to match only a directory (because of the trailing '/') whose name matches 'var' and lives in the root level of the filesystem (because of the leading '/' anchors the pattern to the same level as the file the pattern appears in, i.e. /.gitignore) and no other place.

> (from man gitignore, though reading that and not finding a './' it may
> need improvement

We do not allow relative pathname traversal with "." or "..", do we?

I would be very hesitant to special case "./*.js" to mean "*.js files in the same directory as .gitignore appears", as I think it risks intelligent readers to infer "../foo/*.js" or "../*.js" would take effect, when placed in "bar/.gitignore". A design that spreads an incorrect assumption/expectation is not a good one, I would have to say.