Re: [RFC PATCH 3/4] color.ui config: don't die on unknown values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 31, 2018 at 09:17:41AM +0200, Ævar Arnfjörð Bjarmason wrote:

> > Ævar Arnfjörð Bjarmason  <avarab@xxxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux