Re: .gitattributes override behavior (possible bug, or documentation bug)

Dakota Hawkins writes: > 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

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Wed, Mar 21, 2018 at 4:22 AM, Dakota Hawkins wrote: > Thinking about this a little more, I'm now attracted to the idea that > its .gitignore that's weird. > > As I understand it, .gitignore stops recursion when there's a > directory match (`somedir/`) but also

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Wed, Mar 21, 2018 at 04:35:26AM -0400, Dakota Hawkins wrote: > > 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. :) > > I'd be more

Re: .gitattributes override behavior (possible bug, or documentation bug)

> 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. :) I'd be more than happy to do that! It will take me a while, this (email and

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

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

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

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Tue, Mar 20, 2018 at 11:22:02PM -0400, Dakota Hawkins wrote: > Thinking about this a little more, I'm now attracted to the idea that > its .gitignore that's weird. > > As I understand it, .gitignore stops recursion when there's a > directory match (`somedir/`) but also explicitly allows

Re: .gitattributes override behavior (possible bug, or documentation bug)

Thinking about this a little more, I'm now attracted to the idea that its .gitignore that's weird. As I understand it, .gitignore stops recursion when there's a directory match (`somedir/`) but also explicitly allows nested .gitnore file _as well as_ exclusion (`!*.txt`). So, in the following

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Tue, Mar 20, 2018 at 5:40 AM, Jeff King wrote: > On Tue, Mar 20, 2018 at 12:25:27AM -0400, Dakota Hawkins wrote: > >> > Right. The technical reason is mostly "that is not how it was designed, >> > and it would possibly break some corner cases if we switched it now". >> >> I'm

Re: .gitattributes override behavior (possible bug, or documentation bug)

> So I think the "recommended subset" is basically "everything but these > few constructs". We just need to document them. ;) Mentioned so-far/running list? - Matching directories recursively, or at all I guess (e.g. "/") - (???) Instead: "/*" - Negative matches - (???) Instead: Is there any

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Tue, Mar 20, 2018 at 12:25:27AM -0400, Dakota Hawkins wrote: > > Right. The technical reason is mostly "that is not how it was designed, > > and it would possibly break some corner cases if we switched it now". > > I'm just spitballing here, but do you guys think there's any subset of > the

Re: .gitattributes override behavior (possible bug, or documentation bug)

> Right. The technical reason is mostly "that is not how it was designed, > and it would possibly break some corner cases if we switched it now". I'm just spitballing here, but do you guys think there's any subset of the combined .gitignore and .gitattributes matching functionality that could at

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 11:17:04PM -0400, Dakota Hawkins wrote: > Sorry to tack on to my previous email, but I just thought of this: > > If something like "-diff=lfs" won't do what I (and git-lfs) thought it > would, do you think it would be prudent/reasonable to suggest git-lfs > add a "no-lfs"

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 11:10:26PM -0400, Dakota Hawkins wrote: > > As you noted below, that second line does not match your path, because > > attributes on a directory aren't applied recursively. And it has nothing > > to do with overriding. If you remove the png line entirely, you can see > >

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 08:33:15PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The best you can probably do is: > > > > /.readme-docs/* diff=foo > > > > Since you have no diff.foo.* config, that will behave in the default way > > (including respecting the usual "is

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 11:33 PM, Junio C Hamano wrote: > Jeff King writes: > >> The best you can probably do is: >> >> /.readme-docs/* diff=foo >> >> Since you have no diff.foo.* config, that will behave in the default way >> (including respecting the usual

Re: .gitattributes override behavior (possible bug, or documentation bug)

Jeff King writes: > The best you can probably do is: > > /.readme-docs/* diff=foo > > Since you have no diff.foo.* config, that will behave in the default way > (including respecting the usual "is it binary" checks). So a bit hacky, > but I think it would work as "ignore prior

Re: .gitattributes override behavior (possible bug, or documentation bug)

Sorry to tack on to my previous email, but I just thought of this: If something like "-diff=lfs" won't do what I (and git-lfs) thought it would, do you think it would be prudent/reasonable to suggest git-lfs add a "no-lfs" filter for exactly this case? That way I could have explicit exclusions

Re: .gitattributes override behavior (possible bug, or documentation bug)

Thanks for the quick reply! On Mon, Mar 19, 2018 at 10:34 PM, Jeff King wrote: > On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote: > >> Summary: Trying to apply attributes to file extensions everywhere >> except in one directory. >> >> .gitattributes: >> >>

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote: > Summary: Trying to apply attributes to file extensions everywhere > except in one directory. > > .gitattributes: > > *.[Pp][Nn][Gg] filter=lfs diff=lfs merge=lfs -text > /.readme-docs/ -filter=lfs -diff=lfs -merge=lfs >

.gitattributes override behavior (possible bug, or documentation bug)

According to the gitattributes docs: "When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per attribute." I had a need to do this recently, and while the attributes are git-lfs specific, I think the issue may be generic. Summary: Trying