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

From: Stefan Beller <stefanbeller@gmail.com>
Date: Feb 3, 2015, 02:18 UTC
Message-ID: <CALbm-Ea7X3dDrMUw0sDhWf0sg+zs7oRUkRD+aPzD9fHqB=ZuWQ@mail.gmail.com>
In-Reply-To: <xmqqsieot999.fsf@gitster.dls.corp.google.com>

2015-02-02 11:15 GMT-08:00 Junio C Hamano <gitster@pobox.com>:

Show 41 quoted lines

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

Ok, that's true. So when I started diving into the wonderful world of unix like operating system, one of the first things I was taught is "/" starts an absolute path, while "./foo" or just "foo" starts a relative path. And this stuck with me. Now I realize git treats the repository root literally as the root and hence absolute paths starting with "/" make totally sense inside git as the world stops for git outside its work directory.

Show 5 quoted lines

>
>> (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?

Because we don't have to. It's always relative to the .gitignore file (foo/.gitignore can talk about bar/ and still mean foo/bar), so we don't need to express the relativity in any special way.

Show 8 quoted lines

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

I did not say I'd change the behavior of the ignore rules. I rather meant to say the documentation could be filled with examples for common patterns.

That way you'd not be required to read all the rules and *think* about them, but rather can just copy/paste and hope it works. ;)

Sorry if this sounded otherwise.