Web lists-archives.com

Re: [PATCH/docs] make slash-rules more readable

> the pattern is matched against paths in the directory where the
> `.gitignore` file that has the pattern in it is in, and any of
> its subdirectories (recursively).

> the pattern will match in all directories relative to
> the `.gitignore` file, with infinite depth.

I could not catch the difference between the meaning of both.
However, I think "paths in the directory" and "directories relative to"
are maybe both ambiguous.

Since a pattern without a non-trailing slash must always be a file name or a
folder name, and does not have a leading slash, we could maybe just
say it like this:

        the pattern is matched against all files and folders (recursively)
        from the location of the `.gitignore` file.

> Unlike a pattern without a slash, a pattern with a
> non-trailing slash is matched against paths immediately in
> the directory the `.gitignore` file the pattern appears in
> is stored in, and does not get used in its subdirectories..

I think one can always assume that we talking about the relevant
`.gitignore` file (where the pattern appears in).

Perhaps this covers it all?

        A pattern with a non-trailing slash is always considered
        to begin at the `.gitignore` file location.

followed by your example

> For example, the pattern `doc/frotz/` that appears in
> `.gitignore` at the top-level of the project matches
> `doc/frotz` directory (again, seen from the top-level), but
> not `a/doc/frotz`.

and maybe one more example

        Note that the pattern `doc/frotz` and `/doc/frotz` are
        However `/bar` and `bar` are different. They both match the
        `bar` file or folder at the top level, but only the latter
will also match `foo/bar`
        (when `foo` is at the top level).

This avoids the hustle with the ambiguous path, where it starts, and
trailing or leading slashes. Together with the
two examples it seems to be a good compromise between accuracy and

The alternative would be to say

        A pattern with a non-trailing slash is only matched against any
        path that begins in the directory of the `.gitignore` file.

While this is maybe clearer then saying "pattern [...] always
considered to begin at` it is ambiguous about the slashes.
So a very accuracy but maybe less understandable version would be
something like this:

        A pattern with a non-trailing slash is only matched against any
        path that begins in the directory of the `.gitignore` file.
        For example, if the `.gitignore` file is in folder `doc`
        the path to file  `bar/doc/a/foo` that begins in `doc` is `a/foo`.
        A pattern that matches a path except for a leading slash or
trailing slash
        is still considered a match. It is still valid however,
        that when a pattern ends with a slash, it would only find a
match with a directory.


> Also, a pattern "/doc" matches doc at the current level (i.e. the
> directory in which .gitignore file that the pattern was taken from
> is found) and not in any subdirectories.  Is that clear in the
> proposed update?


However, in the docs is already one paragraph solely dedicated for this case:

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

However, we have already a better and more in detail explained example
in the new
proposal `*` paragraph and and the case with the leading slash is
now a sub-case of `A pattern with a non-trailing slash`
so we might just get rid of the above paragraph?

Thank you for explaining me how the algorithm works procedurally.
It gave some inside of the origin of "If the pattern ends with a slash, it is
removed for the purpose of the following description.."

All the best,