From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Martin Ågren" <martin.agren@gmail.com>,
stas@stason.org, "Git Mailing List" <git@vger.kernel.org>
Subject: Re: git silently ignores include directive with single quotes
Date: Sat, 8 Sep 2018 17:14:37 -0400 [thread overview]
Message-ID: <20180908211436.GA31560@sigill.intra.peff.net> (raw)
In-Reply-To: <87bm97rcih.fsf@evledraar.gmail.com>
On Sat, Sep 08, 2018 at 09:54:14PM +0200, Ævar Arnfjörð Bjarmason wrote:
> The reason missing includes are ignored is that the way this is expected
> to be used is e.g.:
>
> [include]
> path ~/.gitconfig.work
>
> Where .gitconfig.work is some configuration you're going to drop into
> place on your $dayjob servers, but not on your personal machine, even
> though you sync the same ~/.gitconfig everywhere.
>
> A lot of people who use includes rely on this, but I see from this
> thread this should be better documented.
Right, this was an intentional choice at the time the feature was added,
to support this kind of feature. I'd note also that it mirrors other
misspelled keys. E.g.:
[include]
psth = whatever
will also not generate an error. This is also intentional, for two
reasons:
1. Git's config format has always been designed to carry extra keys
used by third-party scripts and porcelain. So we don't actually
know the complete set of valid keys. (Though you could make an
argument that git-core could stake out include.* as its own).
2. It makes using multiple git versions easier in some ways (though
also harder in others). A config key that isn't known to the
current version will be quietly ignored.
Of course those things mean that true spelling mistakes are harder to
catch as such, because Git doesn't know that's what they are. And here
I'm talking config _keys_, not values. So I'm just explaining the
philosophical thinking that led to the "missing file is a silent noop".
It doesn't _have_ to behave the same.
That said, it _does_ behave the same and people are likely depending on
it at this point. So if we introduce a warning, for example, there needs
to be some way to suppress it.
Probably:
[include]
warnOnMissing = false
path = ...
would be enough (with the default being "true").
You could even do:
[include]
warnOnMissing = false
path = one
warnOnMissing = true
path = two
to treat two includes differently (though I'm not sure why you would
want to).
> If we were to make nonexisting files an error, we'd need something like
> an extension of the includeIf syntax added in 3efd0bedc6 ("config: add
> conditional include", 2017-03-01) 3efd0bedc6 ("config: add conditional
> include", 2017-03-01). I.e.:
>
> [includeIfcond "test -e ~/.gitconfig.work"]
> path = ~/.gitconfig.work
>
> Or something like that, this is getting increasingly harder to shove
> into the *.ini config syntax.
I think it would be simpler to just introduce a new key that's a variant
of "path". Like:
[include]
maybePath = ~/.gitconfig.work
Though if it really is just a warning, the "warnOnMissing" above would
make that unnecessary (and it also scales better if we have to end up
adding more behavior tweaks in the future).
-Peff
next prev parent reply other threads:[~2018-09-08 21:14 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-08 18:58 git silently ignores include directive with single quotes Stas Bekman
2018-09-08 19:30 ` Martin Ågren
2018-09-08 19:44 ` Stas Bekman
2018-09-08 19:53 ` Stas Bekman
2018-09-08 20:02 ` Ævar Arnfjörð Bjarmason
2018-09-08 20:13 ` Stas Bekman
2018-09-08 20:28 ` Ævar Arnfjörð Bjarmason
2018-09-08 20:58 ` Stas Bekman
2018-09-09 2:51 ` Paul Smith
2018-09-09 2:57 ` Stas Bekman
2018-09-08 19:54 ` Ævar Arnfjörð Bjarmason
2018-09-08 20:04 ` Stas Bekman
2018-09-08 20:16 ` Ævar Arnfjörð Bjarmason
2018-09-08 21:14 ` Jeff King [this message]
2018-09-08 22:10 ` Ramsay Jones
2018-09-09 2:33 ` Jeff King
2018-09-11 20:36 ` Junio C Hamano
2018-09-11 20:57 ` Jeff King
2018-09-23 22:48 ` Stas Bekman
2018-09-24 21:08 ` Ævar Arnfjörð Bjarmason
2018-09-24 23:20 ` Stas Bekman
2018-09-24 22:24 ` [PATCH 0/1] " Philip Oakley
2018-09-24 23:05 ` Stas Bekman
2018-09-24 22:24 ` [PATCH 1/1] config doc: highlight the name=value syntax Philip Oakley
2018-09-25 22:03 ` Junio C Hamano
2018-09-08 22:32 ` git silently ignores include directive with single quotes Ævar Arnfjörð Bjarmason
2018-09-09 2:29 ` Jeff King
2018-09-08 21:22 ` Jeff King
2018-09-08 22:49 ` Stas Bekman
2018-09-09 2:30 ` Jeff King
2018-09-10 17:04 ` Junio C Hamano
2018-09-10 17:14 ` Jonathan Nieder
2018-09-10 18:30 ` Junio C Hamano
2018-09-10 18:35 ` Jonathan Nieder
2018-09-10 19:17 ` Junio C Hamano
2018-09-10 19:52 ` Stas Bekman
2018-09-10 20:10 ` Junio C Hamano
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=20180908211436.GA31560@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=martin.agren@gmail.com \
--cc=stas@stason.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).