From: Jeff King <email@example.com> To: Dakota Hawkins <firstname.lastname@example.org> Cc: Git <email@example.com> Subject: Re: .gitattributes override behavior (possible bug, or documentation bug) Date: Mon, 19 Mar 2018 22:34:24 -0400 [thread overview] Message-ID: <20180320023423.GA10143@sigill.intra.peff.net> (raw) In-Reply-To: <CAHnyXxRX4+sMJCNG6f9xtsDO6bdqRS-U6TAYO47OKQjH8bGzbg@mail.gmail.com> 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 > > Make some data: > > echo "asldkjfa;sldkjf;alsdjf" > ./.readme-docs/test.png > git add -A 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 that we still do not match it. You need to use "*" to match the paths. You may also find that "-diff=lfs" does not do quite what you want. There is no way to say "cancel any previous attribute", which I think is what you're trying for here. You can only override it with a new value. So: /.readme-docs/* -diff says "do not diff this". And: /.readme-docs/* diff says "diff this as text, even if it looks binary". 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 diff". And I think filter and merge drivers should work the same. > Is this me misunderstanding something in the documentation? I would > expect "./.readme-docs/" to match "./.readme-docs/test.png" and > override the earlier "*.[Pp][Nn][Gg]" attributes. > > I have found the following overrides to work in lieu of the directory match: > > /.readme-docs/* -filter=lfs -diff=lfs -merge=lfs > /.readme-docs/**/* -filter=lfs -diff=lfs -merge=lfs > > ...but I don't see a justification in the documentation for this > working and the original directory filter not working. I could not find anything useful in gitattributes(5). There's some old discussion here: https://firstname.lastname@example.org/ which makes it clear that attributes aren't recursive, but it's probably worth calling out in the documentation. In fact, I think the current documentation is a bit misleading in that it says "patterns are matched as in .gitignore", which is clearly not the case here. I think just "/.readme-docs/**" should be sufficient for your case. You could also probably write "*" inside ".readme-docs/.gitattributes", which may be simpler (you don't need "**" there because patterns without a slash are just matched directly against the basename). -Peff
next prev parent reply other threads:[~2018-03-20 2:34 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 [this message] 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 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180320023423.GA10143@sigill.intra.peff.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: .gitattributes override behavior (possible bug, or documentation bug)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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: https://80x24.org/mirrors/git.git 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).