git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Dakota Hawkins <dakota@dakotahawkins.com>
To: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>
Cc: Git <git@vger.kernel.org>
Subject: Re: .gitattributes override behavior (possible bug, or documentation bug)
Date: Tue, 20 Mar 2018 00:25:27 -0400	[thread overview]
Message-ID: <CAHnyXxQMbnNam=oB_B57xDZBaMPRn_8hfKtostHPV6nBHbTBog@mail.gmail.com> (raw)
In-Reply-To: <20180320040411.GB12938@sigill.intra.peff.net>

> 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 least serve as a good "best-practices, going forward"
(because of consistency) for both? I will say every time I do this for
a new repo and have to do something even slightly complicated or
different from what I've done before with .gitattributes/.gitignore
that it takes me a long-ish time to figure it out. It's like I'm
vaguely aware of pitfalls I've encountered in the past in certain
areas but don't remember exactly what they are, so I consult the docs,
which are (in sum) confusing and lead to more time spent
trying/failing/trying/works/fails-later/etc.

One "this subset of rules will work for both this way" would be
awesome even if the matching capabilities are technically divergent,
but on the other hand that might paint both into a corner in terms of
functionality.

>> > 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).
>>
>> Wouldn't that make the "*" inside ".readme-docs/.gitattributes",
>> technically recursive when "*" matches a directory?
>
> Sort of. The pattern is applied recursively to each basename, but the
> pattern itself does not match recursively. That's probably splitting
> hairs, though. :)

I understand, but if I think about it too much I feel the overwhelming
urge to stop thinking about it :)

>> It's always seemed to me that both were necessary to explicitly match
>> things in a directory and its subdirectories (example, IIRC: "git
>> ls-files -- .gitattributes" vs "git ls-files -- .gitattributes
>> **/.gitattributes"). Maybe that example is peculiar in that its a
>> dotfile and can't have a wildcard before the dot?
>
> Those are pathspecs, which are not quite the same as gitattributes. They
> don't do the magic basename matching.
>
> For pathspecs a "*" matches across slashes, which is what allows "git
> log -- '*.h'" to work (but not a suffix wildcard like 'foo*').

Same comment -- makes sense but hard to want to think too much about.

>> I guess my takeaway is that it would be _good_ if the gitattributes
>> documentation contained the caveat about not matching directories
>> recursively, but _great_ if gitattributes and gitignore (and whatever
>> else there is) were consistent.
>
> I agree it would be nice if they were consistent (and pathspecs, too).
> But unfortunately at this point there's a maze of backwards
> compatibility to deal with.
>
> -Peff

Again, as above, what if there were a subset of functionality git
could recommend to avoid inconsistencies?

  parent reply	other threads:[~2018-03-20  4:25 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       ` Dakota Hawkins [this message]
2018-03-20  4:40         ` .gitattributes override behavior (possible bug, or documentation bug) 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='CAHnyXxQMbnNam=oB_B57xDZBaMPRn_8hfKtostHPV6nBHbTBog@mail.gmail.com' \
    --to=dakota@dakotahawkins.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --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).