git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] make slash-rules more readable

From
Johannes Sixt <j6t@kdbg.org>
Date
May 19, 2019, 06:59 UTC
Message-ID
<b98df9fc-384d-1d73-170c-691630454287@kdbg.org>
In-Reply-To
<20190518141337.14919-1-admin@in-ici.net>
Am 18.05.19 um 16:13 schrieb Dr. Adam Nielsen:
Show 61 quoted lines
> - - If the pattern ends with a slash, it is removed for the
> -   purpose of the following description, but it would only find
> + - A slash `/` is used as a directory separator. A leading and trailing
> +   slash have special meaning and are explained in the following.
> +
> + - If the pattern ends with a slash, 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).
> -
> - - Otherwise, Git treats the pattern as a shell glob: "`*`" matches
> -   anything except "`/`", "`?`" matches any one character except "`/`"
> -   and "`[]`" matches one character in a selected range. See
> -   fnmatch(3) and the FNM_PATHNAME flag for a more detailed
> -   description.
> -
> - - A leading slash matches the beginning of the pathname.
> -   For example, "/{asterisk}.c" matches "cat-file.c" but not
> -   "mozilla-sha1/sha1.c".
> +   directory `foo`, 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 end with a slash, it would find a match
> +   with a file or directory.
> +
> + - If the pattern contains no slash or only a trailing slash,
> +   the pattern is matched against all files and folders (recursively)
> +   from the location of the `.gitignore` file.
> +   For example, `frotz/` matches `frotz` and `a/frotz` that
> +   is a directory (relative from the `.gitignore` file).
> +   Otherwise the pattern is matched relative to the
> +   location of the `.gitignore` file.
> +   For example, `doc/frotz/` matches `doc/frotz` directory, but not
> +   `a/doc/frotz` (relative from the `.gitignore` file).
> +
> + - The above pargraph also includes the case of a leading slash.
> +   For example, the pattern `/bar` only matches the file or
> +   folder `bar` that is at the same location as the `gitignore`
> +   file. Whereas the pattern `bar` would also match in folders
> +   below the `gitignore`  file.
> +
> + - An asterisk "`*`" matches anything except a slash.
> +   A pattern "foo/*", for example, matches "foo/test.json"
> +   (a regular file), "foo/bar" (a diretory), but it does not match
> +   "foo/bar/hello.c" (a regular file), as the asterisk in the
> +   patter does not match "bar/hello.c" which has a slash in it.
> +   The character "`?`" matches any one character except "`/`".
> +   The range notation, e.g. `[a-zA-Z]`, can be used to match
> +   one of the characters in a range. See fnmatch(3) and the
> +   FNM_PATHNAME flag for a more detailed description.
>  
>  Two consecutive asterisks ("`**`") in patterns matched against
>  full pathname may have special meaning:

All those examples unterrupt the flow of thought in a way that makes it diffcult to follow the reasoning. May I suggest a different approach to upate this text? Provide two patches:

- Patch 1/2 updates the Examples section such that it contains all
  examples that you provide in the text above, with explanation.
  Perhaps refer to the Examples section early above the rules.
- Patch 2/2 updates the rules section without giving examples.
Let's see how that works out.
The examples in the Examples section are overly technical by saying
   $ cat .gitignore
   vmlinux*
   $ ls arch/foo/kernel/vm*
   arch/foo/kernel/vmlinux.lds.S
   $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore

I think that this could be made more pleasent to read if one would not have to use a mental shell interpreter. ;)

-- Hannes
Previous: Junio C Hamano
Message 3 of 3 in “make slash-rules more readable”
  1. make slash-rules more readableDr. Adam Nielsen, May 18, 2019
  2. Junio C HamanoMay 19, 2019
  3. Johannes SixtMay 19, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.