Re: [RFC PATCH 3/4] color.ui config: don't die on unknown values
- From
Jeff King <peff@peff.net>
- Date
- Jun 1, 2018, 05:53 UTC
- Message-ID
- <20180601055355.GC8292@sigill.intra.peff.net>
- In-Reply-To
- <87h8mo9tuy.fsf@evledraar.gmail.com>
On Thu, May 31, 2018 at 09:17:41AM +0200, Ævar Arnfjörð Bjarmason wrote:
Show 19 quoted lines
> > Æ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