list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Dakota Hawkins <>
To: Jeff King <>
Cc: Duy Nguyen <>,
	Junio C Hamano <>, Git <>
Subject: Re: .gitattributes override behavior (possible bug, or documentation bug)
Date: Wed, 21 Mar 2018 03:36:09 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> I think that ignoring all of /ignore-most/ is much more efficient, since
> we don't have to enumerate the paths inside it at all (which is why the
> current behavior works as it does).

That's definitely true, but I wonder what the impact would be for most
cases (even for most cases with large repos and larges sets of ignore

Most of my .gitignore patterns weren't hand-written
( is pretty neat), but there are a ton of
patterns like `dir/`...

I think if I were designing it from scratch and knew what I know now
I'd probably argue that behavior should be declarative (`dir/*
recurse=false` or something), but we can't really get there from here.

At any rate, would it at least be a good idea to make the "trailing
slash halts recursion, won't consider nested .gitignore files"
explicit in the `.gitignore` doc? Unless I'm missing it, I don't think
that behavior is called out (or at least not called out concisely/in
one place). It looks like this is all there is:

    "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

Also, I'm not sure what the "following description" is in "it is
removed for the purpose of the following description". Is that trying
to imply "excluded from the rest of the doc"?

- Dakota

  reply	other threads:[~2018-03-21  7:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-20  1:49 Dakota Hawkins
2018-03-20  2:34 ` Jeff King
2018-03-20  3:10   ` Dakota Hawkins
2018-03-20  3:17     ` Dakota Hawkins
2018-03-20  4:12       ` Jeff King
2018-03-20  4:04     ` Jeff King
2018-03-20  4:14       ` [PATCH] doc/gitattributes: mention non-recursive behavior Jeff King
2018-03-20  4:28         ` Dakota Hawkins
2018-03-20 16:41         ` Duy Nguyen
2018-03-21  6:50           ` Jeff King
2018-03-21 16:16             ` Duy Nguyen
2018-03-23  9:12               ` Jeff King
2018-03-20  4:25       ` .gitattributes override behavior (possible bug, or documentation bug) Dakota Hawkins
2018-03-20  4:40         ` Jeff King
2018-03-20  4:49           ` Dakota Hawkins
2018-03-20 16:28           ` Duy Nguyen
2018-03-21  3:22             ` Dakota Hawkins
2018-03-21  6:52               ` Jeff King
2018-03-21  7:36                 ` Dakota Hawkins [this message]
2018-03-21  7:44                   ` Dakota Hawkins
2018-03-21  7:50                   ` Jeff King
2018-03-21  8:35                     ` Dakota Hawkins
2018-03-21  8:36                       ` Jeff King
2018-03-21 16:18                   ` Junio C Hamano
2018-03-21 16:07               ` Duy Nguyen
2018-03-20  3:33   ` Junio C Hamano
2018-03-20  3:40     ` Dakota Hawkins
2018-03-20  3:45     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: .gitattributes override behavior (possible bug, or documentation bug)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).