Re: .gitattributes override behavior (possible bug, or documentation bug)
On Wed, Mar 21, 2018 at 03:36:09AM -0400, Dakota Hawkins wrote: > > 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 > files). Probably not that much CPU, but it used to be quite annoying to fault in the dcache for an infrequently used hierarchy. These days I generally have an SSD and lots of memory for disk caching, so I don't know if it would still be. On systems where readdir/stat are slower than Linux it might be noticeable for a big hierarchy. > 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: Yeah, it's definitely come up multiple times over the years. I don't know what all is in gitignore(5), but if it's not mentioned it probably should be. > "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)." > > 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"? I think it means "for the rest of the description of how the patterns work". I.e., "foo/" matches as "foo" when the rest of the matching rules are applied. I agree it's a bit awkward. Patches welcome. :) -Peff
Re: .gitattributes override behavior (possible bug, or documentation bug)
One extra note: I was burned by this just a few hours ago in a new repo (but because of this discussion I realized what the problem was pretty quickly). In the top-level .gitignore I had build/ ... !alpine/build/ where `build/` was a stock ignore line among hundreds that I blindly pasted in there, and the exclusion was an attempt to exclude some things that shouldn't have been ignored. Even in the same file, the exclusion doesn't work. I had to change it to: build/* ... !alpine/build/ Good times :) - Dakota On Wed, Mar 21, 2018 at 3:36 AM, Dakota Hawkins wrote: >> 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 > files). > > Most of my .gitignore patterns weren't hand-written > (https://www.gitignore.io/ 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 > Git)." > > 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
Re: .gitattributes override behavior (possible bug, or documentation bug)
> 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 files). Most of my .gitignore patterns weren't hand-written (https://www.gitignore.io/ 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 Git)." 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
