From: Dakota Hawkins <firstname.lastname@example.org> To: Jeff King <email@example.com>, Junio C Hamano <firstname.lastname@example.org> Cc: Git <email@example.com> 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?
next prev 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' \ --firstname.lastname@example.org \ --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).