git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Jacob Keller <jacob.keller@gmail.com>,
	Aaron Pelly <aaron@pelly.co>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: Expanding Includes in .gitignore
Date: Sun, 30 Oct 2016 10:09:25 +0700	[thread overview]
Message-ID: <CACsJy8AMDW2w=xnAYDLTEN5MVxj+5JuiFnXGD1JFbD=RgLDcfA@mail.gmail.com> (raw)
In-Reply-To: <20161027210458.ptzh4y75dkfaixeo@sigill.intra.peff.net>

On Fri, Oct 28, 2016 at 4:04 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:
>
>> > I think the normal behavior in such "foo.d" directory is to just sort
>> > the contents lexically and read them in order, as if they were all
>> > concatenated together, and with no recursion. I.e., behave "as if" the
>> > user had run "cat $dir/*".
>>
>> Yea, this is the normal behavior, and the user is expected to order
>> their files lexically such as "00-name", "50-name" and so on. Pretty
>> traditional for a lot of newer configurations.
>
> One thing I will say about this approach is that you can implement it
> without any changes in git by doing:
>
>   path=.git/info/exclude
>   cat $path.d/* >$path
>
> and I have seen several config mechanisms basically do that (e.g.,
> Debian packaging for a program that doesn't have its own ".d" mechanism,
> but needs to grab config provided by several separate packages).

My first thought at this .git/info/exclude.d was "oh no I have to
teach untracked cache about new dependencies, or at least disable it
until it can deal with exclude.d", but this "cat" approach simplifies
things and should keep untracked cache unchanged.

There may be complication with negative patterns though. The user may
want to limit the effect of negative patterns within individual
exclude files in exclude.d so a negative pattern in exclude.d/a won't
influence anything in exclude.d/b (easier to reason, safer to compose
different exclude sets). The plain "cat" would lose file boundary info
that we need. I'm not sure. But I'll dig more into it when patches
show up.
-- 
Duy

  parent reply	other threads:[~2016-10-30  3:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-27  0:22 Expanding Includes in .gitignore Aaron Pelly
2016-10-27  2:22 ` Stefan Beller
2016-10-27  9:51   ` Aaron Pelly
2016-10-27  8:19 ` Alexei Lozovsky
2016-10-27 10:33   ` Aaron Pelly
2016-10-27 10:50 ` Jeff King
2016-10-27 19:48   ` Jacob Keller
2016-10-27 20:59     ` Aaron Pelly
2016-10-27 21:04     ` Jeff King
2016-10-27 21:26       ` Aaron Pelly
2016-10-27 21:39       ` Jacob Keller
2016-10-30  3:09       ` Duy Nguyen [this message]
2016-10-27 20:28   ` Aaron Pelly
2016-10-27 20:55     ` Jeff King
2016-10-27 21:07       ` Jeff King
2016-10-27 22:30         ` Aaron Pelly
2016-10-27 23:07         ` Aaron Pelly
2016-10-28  2:54         ` Junio C Hamano
2016-10-28  9:32           ` Aaron Pelly
2016-10-30  3:16             ` Duy Nguyen
2016-10-30 12:54             ` Jeff King
2016-10-27 21:55       ` Aaron Pelly
2016-10-27 22:17         ` Aaron Pelly
2016-10-28  8:10           ` 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='CACsJy8AMDW2w=xnAYDLTEN5MVxj+5JuiFnXGD1JFbD=RgLDcfA@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=aaron@pelly.co \
    --cc=git@vger.kernel.org \
    --cc=jacob.keller@gmail.com \
    --cc=peff@peff.net \
    /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).