git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Dakota Hawkins <dakota@dakotahawkins.com>
Cc: Git <git@vger.kernel.org>
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://public-inbox.org/git/slrnkldd3g.1l4.jan@majutsushi.net/

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

  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 .gitattributes override behavior (possible bug, or documentation bug) 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 \
    --to=peff@peff.net \
    --cc=dakota@dakotahawkins.com \
    --cc=git@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).