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

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <stefanbeller@gmail.com> writes:

> 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.