From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>,
Stefan Beller <sbeller@google.com>
Subject: Re: [RFC PATCH 3/4] color.ui config: don't die on unknown values
Date: Fri, 1 Jun 2018 01:53:55 -0400 [thread overview]
Message-ID: <20180601055355.GC8292@sigill.intra.peff.net> (raw)
In-Reply-To: <87h8mo9tuy.fsf@evledraar.gmail.com>
On Thu, May 31, 2018 at 09:17:41AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> >
> >> Before this change git will die on any unknown color.ui values:
> >>
> >> $ git -c color.ui=doesnotexist show
> >> fatal: bad numeric config value 'doesnotexist' for 'color.ui': invalid unit
> >
> > I do not think "unit" is correct, so there may be some room for
> > improvement. For _this_ particular case, I agree that it is not the
> > end of the world if we did not color the output (because we do not
> > know what the 'doesnotyetexist' token from the future is trying to
> > tell us), but as a general principle, we should diagnose and die, if
> > a misconfiguration is easy to correct.
>
> Many users (including myself) use the same ~/.gitconfig on many
> different machines with different git versions. Maybe at some point I'm
> willing to set the new setting to a value I know is supported on most of
> them, but it sucks at that point if I logging into 1-3% of old machines
> ends up killing git on any invocation.
One way I've dealt with this in the past is by breaking my config into
multiple files, and using an "[include]" for the relevant ones in each
environment. That's not quite turn-key, because you need some way to
decide which to include and which not to, and there's no good way to
have Git invoke that.
Some options I've pondered:
- we could add [includeIf "version:2.18.0"] for a minimum-version
check
- we could add [includeIf "env:FOO"] to check "$FOO" as a boolean.
That punts the work to your shell environment, but it's flexible
enough to let you decide however you like (checking git version,
machine name, etc)
- similarly, we could add [includeIf "sh:test -f /etc/foo"], but
running actual shell is nasty for a lot of reasons. Relying on the
environment punts on that.
You can actually do the environment thing today, but it's a bit hacky.
E.g., with this in your .profile or similar:
git version |
perl -ne '
my $ok = /git version (\d+\.\d+)/ && $1 >= 2.15;
exit !$ok;
' &&
export GIT_CONFIG_PARAMETERS="'include.path=$HOME/.gitconfig-2.15'"
I know that's more work than just having Git ignore config it doesn't
understand, but it's also a lot more flexible (instead of just ignoring
and using the defaults, you can say "for this version do X, for that one
do Y").
-Peff
next prev parent reply other threads:[~2018-06-01 5:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 21:06 [PATCH 0/4] color.ui docs & add color.ui=isatty Ævar Arnfjörð Bjarmason
2018-05-30 21:06 ` [PATCH 1/4] config doc: move color.ui documentation to one place Ævar Arnfjörð Bjarmason
2018-05-31 5:25 ` Jeff King
2018-05-31 7:09 ` Ævar Arnfjörð Bjarmason
2018-06-01 5:31 ` Jeff King
2018-05-30 21:06 ` [PATCH 2/4] config doc: clarify "to a terminal" in color.ui Ævar Arnfjörð Bjarmason
2018-05-31 5:27 ` Jeff King
2018-05-30 21:06 ` [RFC PATCH 3/4] color.ui config: don't die on unknown values Ævar Arnfjörð Bjarmason
2018-05-30 22:32 ` Stefan Beller
2018-05-30 23:05 ` Junio C Hamano
2018-05-31 7:17 ` Ævar Arnfjörð Bjarmason
2018-06-01 5:53 ` Jeff King [this message]
2018-05-30 21:06 ` [RFC PATCH 4/4] color.ui config: add "isatty" setting Ævar Arnfjörð Bjarmason
2018-05-30 22:57 ` Junio C Hamano
2018-05-31 7:07 ` Ævar Arnfjörð Bjarmason
2018-05-31 5:38 ` Jeff King
2018-05-31 7:01 ` Ævar Arnfjörð Bjarmason
2018-06-01 5:30 ` 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=20180601055355.GC8292@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=sbeller@google.com \
/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).