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

Re: Change in .gitignore handling: intended or bug?

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 10, 2016, 00:37 UTC
Message-ID
<xmqqd1r3f9rc.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<CACsJy8D=OjLBN-EXyKM4NnGhSGftYX+RAaR9fg8ML3QWAAb+iQ@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
Show 11 quoted lines
> A bit off topic, but these two paragraphs may need rephrasing, I don't
> really understand what it's trying to say
>
>  - 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).
>
> Not sure why "relative to the location of .gitignore file" matters. We
> basically just take `basename $path` out and try to match it.

That is because the documentation was written with a single consistent matching mode in mind: you match various patterns against the FULL path in the repository, no matter where you find the path. If you find a pattern "*.c" in d/.gitignore file, a path d/hello.c matches, even though '*.c' does not match 'd/hello.c' in the shell glob sense, and the rule needs to clarify that the leading directory part "d/" in the path "d/hello.c" does not participate when matching it against the pattern "*.c" taken from "d/.gitignore" file.

If you start from a mindset to match hello.c part with *.c when you find both in d/ directory, "relative to the location" part would sound redundant or even confusing.

Show 9 quoted lines
>  - Otherwise, Git treats the pattern as a shell glob suitable
>    for consumption by fnmatch(3) with the FNM_PATHNAME flag:
>    wildcards in the pattern will not match a / in the pathname.
>    For example, "Documentation/{asterisk}.html" matches
>    "Documentation/git.html" but not "Documentation/ppc/ppc.html"
>    or "tools/perf/Documentation/perf.html".
>
> Perhaps "Otherwise" can be stated explicitly that "if the pattern does
> contain any slash, besides the trailing one". 

Yeah, I think there originally was just two (it has slasn or it doesn't) and "If ..." followed by "Otherwise" was clear enough, but spellin it out would not hurt.

Previous: Duy NguyenNext: Junio C Hamano
Message 26 of 28 in “Change in .gitignore handling: intended or bug?”
  1. Charles StrahanMar 4, 2016
  2. Duy NguyenMar 4, 2016
  3. Kevin DaudtMar 4, 2016
  4. Charles StrahanMar 4, 2016
  5. Kevin DaudtMar 4, 2016
  6. Duy NguyenMar 4, 2016
  7. Junio C HamanoMar 4, 2016
  8. Junio C HamanoMar 4, 2016
  9. Duy NguyenMar 5, 2016
  10. Duy NguyenMar 5, 2016
  11. Charles StrahanMar 5, 2016
  12. Junio C HamanoMar 5, 2016
  13. Junio C HamanoMar 7, 2016
  14. Junio C HamanoMar 8, 2016
  15. Duy NguyenMar 8, 2016
  16. Junio C HamanoMar 8, 2016
  17. Duy NguyenMar 9, 2016
  18. Junio C HamanoMar 9, 2016
  19. Junio C HamanoMar 9, 2016
  20. dir.c: fix dir re-inclusion rules with "NODIR" and "MUSTBEDIR"Nguyễn Thái Ngọc Duy, Mar 9, 2016
  21. Junio C HamanoMar 9, 2016
  22. Duy NguyenMar 10, 2016
  23. Duy NguyenMar 9, 2016
  24. Junio C HamanoMar 9, 2016
  25. Duy NguyenMar 10, 2016
  26. Junio C HamanoMar 10, 2016
  27. Junio C HamanoMar 10, 2016
  28. Duy NguyenMar 10, 2016

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.