Re: [PATCH] clean: new option --exclude-from
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 2, 2015, 16:40 UTC
- Message-ID
- <xmqqlh9c6byy.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20151202024403.GA29329@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 16 quoted lines
> On Tue, Dec 01, 2015 at 06:18:30PM -0800, Junio C Hamano wrote: > >> It is likely that existing users are already using $HOME/.gitconfig >> that sets core.excludesfile=$HOME/.gitconfig as the personal >> fallback, that is overriden, not tweaked, by project specific >> settings of the same variable in .git/config, so that would not fly >> very well, I suspect. > > Maybe. I would think the more common setup is: > > 1. Personal exclude files (e.g., your editor's backup files) come from > ~/.gitconfig. > > 2. Per-project personal excludes go directly into .git/info/exclude. > > But you're right that it would be a backwards-incompatible change.
No question about it, but at the same time I can sort of see how useful being able to read from more than one would be.
But for this particular one, I viewed the topic as adding a new option as a shorter way for passing multiple -e <pattern> options on the command line. When viewed that way, even if core.excludesfile were multi-valued, I wouldn't have imagined that people would try to use that mechanism for such a purpose--for one thing, the precedence order is wrong for that purpose, isn't it?