Re: How to undo previously set configuration?

[Jeff King]

On Fri, Apr 06, 2018 at 05:57:39PM +0100, Rafael Ascensao wrote:

> On Fri, Apr 6, 2018 at 4:55 PM, Olaf Hering  wrote:
> >
> > This does not work. Initially I copied the global config into the
> > repo and set all unwanted values to , like 'smtpuser='.
> > Perhaps the config parser recognized that fact, but the consumer
> > does not?
> >
> 
> Today someone asked on #git for a way to disable diff.external for a
> single command.
> Without thinking much I suggested $git -c diff.external= diff; which fails 
> with:
> `fatal: cannot run : No such file or directory`
> 
> In this particular case there was `--no-ext-diff` to get around this
> and the case was promptly resolved.
> Just another another example where setting configuration values to
> "empty" doesn't translate to "disable this option".

Yeah, I think it would make sense in that case to reset
external_diff_cmd_cfg to NULL. I'd almost say that git_config_string()
should recognize and handle this case, but I suspect there are some
callers who need special behavior (e.g., to set it back to some
particular string).

-Peff

Re: How to undo previously set configuration?

[Rafael Ascensao]

On Fri, Apr 6, 2018 at 4:55 PM, Olaf Hering  wrote:
>
> This does not work. Initially I copied the global config into the repo and 
> set all unwanted values to , like 'smtpuser='. Perhaps the config 
> parser recognized that fact, but the consumer does not?
>

Today someone asked on #git for a way to disable diff.external for a
single command.
Without thinking much I suggested $git -c diff.external= diff; which fails with:
`fatal: cannot run : No such file or directory`

In this particular case there was `--no-ext-diff` to get around this
and the case was promptly resolved.
Just another another example where setting configuration values to
"empty" doesn't translate to "disable this option".

Re: How to undo previously set configuration?

[Jeff King]

On Fri, Apr 06, 2018 at 05:55:56PM +0200, Olaf Hering wrote:

> > The general strategy in Git's config is that instead of "unsetting",
> > you
> > should overwrite with whatever value you _do_ want. So a config option
> > like sendemail.smtpauth should accept some kind of empty or "none" value
> > to disable auth.
> > 
> > Most single-value config options should work this way (and if one
> > doesn't, I'd say that's a bug we should fix).
> 
> This does not work. Initially I copied the global config into the repo
> and set all unwanted values to , like 'smtpuser='. Perhaps the
> config parser recognized that fact, but the consumer does not?

Yes. That logic is handled by the consumer (especially in the case of
send-email, which is a perl script, the code runs in a totally separate
process from the config parser). Naively I'd think that:

  [sendemail]
  smtpAuth =

would do what you want, and then we'd ignore smtpUser completely.
It looks like the smtp_auth_maybe function uses perl's "defined" there,
though. Perhaps it should treat the empty string the same there.

(Or maybe it's something else; I don't use send-email myself, and in a
few trivial examples I couldn't get it to complain about similar
config).

-Peff

Re: How to undo previously set configuration?

[Olaf Hering]

Am Thu, 5 Apr 2018 12:32:27 -0400
schrieb Jeff King :

> The general strategy in Git's config is that instead of "unsetting", you
> should overwrite with whatever value you _do_ want. So a config option
> like sendemail.smtpauth should accept some kind of empty or "none" value
> to disable auth.
> 
> Most single-value config options should work this way (and if one
> doesn't, I'd say that's a bug we should fix).

This does not work. Initially I copied the global config into the repo and set 
all unwanted values to , like 'smtpuser='. Perhaps the config parser 
recognized that fact, but the consumer does not?

Olaf


pgpbEK2CI1ZX0.pgp
Description: Digitale Signatur von OpenPGP

Re: How to undo previously set configuration?

[Jeff King]

On Thu, Apr 05, 2018 at 03:25:25PM +0200, Olaf Hering wrote:

> Am Thu, 05 Apr 2018 13:21:02 +0200
> schrieb Ævar Arnfjörð Bjarmason :
> 
> > I'm assuming you mean something like:
> > [user]
> > # This is an error
> > -email
> 
> Yes. Just some flag to say "whatever value this variable has from
> earlier parsing, forget it in case it really exists". Just like "unset
> PATH" in bash.
> 
> I do not know the git internals, so can not really help with the case.

The general strategy in Git's config is that instead of "unsetting", you
should overwrite with whatever value you _do_ want. So a config option
like sendemail.smtpauth should accept some kind of empty or "none" value
to disable auth.

Most single-value config options should work this way (and if one
doesn't, I'd say that's a bug we should fix).

Multi-valued config (e.g., "remote.*.fetch") is harder, since it's
inherently a list where each new instance adds to the list. We've
discussed there having an empty value reset the list, but it's not
applied consistently.

-Peff

Re: How to undo previously set configuration?

[Olaf Hering]

Am Thu, 05 Apr 2018 13:21:02 +0200
schrieb Ævar Arnfjörð Bjarmason :

> I'm assuming you mean something like:
> [user]
> # This is an error
> -email

Yes. Just some flag to say "whatever value this variable has from earlier 
parsing, forget it in case it really exists". Just like "unset PATH" in bash.

I do not know the git internals, so can not really help with the case.

Olaf


pgpnLQis2dHKn.pgp
Description: Digitale Signatur von OpenPGP

RE: How to undo previously set configuration?

[Randall S. Becker]

On April 5, 2018 7:21 AM, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Apr 05 2018, Olaf Hering wrote:
> 
> > Am Thu, 05 Apr 2018 10:42:15 +0200
> > schrieb Ævar Arnfjörð Bjarmason :
> >
> >> I've been meaning to work on this but haven't figured out a good syntax
> for it (suggestions welcome!).
> >
> > Just prefix the knob with something like "no." or "-" or whatever to 
> > indicate
> that it never happened.
> 
> Those wouldn't work, respectively, because:
> 
>  a) For 'no.' there would be no way to override three-level keys,
> because prefixing such a key with "no" would introduce a 4th nesting
> level, which would be incompatible with existing config parsers.
> 
>  b) Similarly a prefix of - dies in git now. Unless I misunderstand
> you. I'm assuming you mean something like:
> 
> [user]
> # This is an error
> -email
> 
> Although I see we don't ignore or error out on:
> 
> [user "-email"]
> foo=bar
> 
>But that's back to problem a), and also looks ugly since you need
>something like the extra foo=bar so we'll pay attention to it.
> 
> Also it's important that the syntax leaves room for item #1 that I mentioned,
> 
> I.e. not just ignore stuff like user.email, but being able to specify where 
> from
> you'd like to ignore that. Sometimes your local sysadmin is overzealous with
> his /etc/gitconfig settings and you'd like to quarantine just that, but pay
> attention to everything else in ~/.gitconfig, or similarly in
> /some/repo/.git/config ignore your usual custom sendemail.* from
> ~/.gitconfig but not /etc/gitconfig, so the semantics can't just be "clear
> existing".
> 
> But of course, you might say that it *should* be a syntax error because if you
> rely on this feature and downgrade, you don't want to suddenly pay
> attention to the sendemail.* config again.
> 
> I think that's an acceptable failure mode, and better than the syntax error,
> because that's exactly what we have now, so this is similar to e.g. the
> conditional include directive which was understood but just copmletely
> ignored by older versions.
> 
> So we're OK with getting different config between versions with new
> releases, but at all costs don't want to have new releases introduce
> constructs that older gits error out on, and let's say hypothetically we
> supported something like:
> 
> [user "-email"]
> [user]
> email = ...
> 
> Even `git config -l` on older version won't show that "user.-email", and it's
> better if older tools at least understand the syntax, even though they don't
> pick up on the magic.

I may be missing something but..

Another completely different approach to "undoing" configurations is to 
consider using git for this. Have a repository set up for your ~ directory, 
ignoring content other than .*, so you would ignore any sub-repositories at 
this level. Then manage your configuration as any other repo.

For configurations that are not user-specific, use in-repository configurations 
instead of system and global, so your undo is also handled by git. However, you 
can version control your /etc directory as well. We do that to detect changes 
(as a practical example, we have /etc/.git with some bits ignored but critical 
things involving rc.d, and the system git configurations are managed content in 
that repository. This implies our Ops team has to use git to make changes - a 
good thing - and 'git status' and 'git log' tells me immediately if someone 
changed something.

Undo becomes a git operation in both situations.

This may be complete OT, but I thought it might help

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

Re: How to undo previously set configuration?

[Ævar Arnfjörð Bjarmason]

On Thu, Apr 05 2018, Olaf Hering wrote:

> Am Thu, 05 Apr 2018 10:42:15 +0200
> schrieb Ævar Arnfjörð Bjarmason :
>
>> I've been meaning to work on this but haven't figured out a good syntax for 
>> it (suggestions welcome!).
>
> Just prefix the knob with something like "no." or "-" or whatever to indicate 
> that it never happened.

Those wouldn't work, respectively, because:

 a) For 'no.' there would be no way to override three-level keys,
because prefixing such a key with "no" would introduce a 4th nesting
level, which would be incompatible with existing config parsers.

 b) Similarly a prefix of - dies in git now. Unless I misunderstand
you. I'm assuming you mean something like:

[user]
# This is an error
-email

Although I see we don't ignore or error out on:

[user "-email"]
foo=bar

   But that's back to problem a), and also looks ugly since you need
   something like the extra foo=bar so we'll pay attention to it.

Also it's important that the syntax leaves room for item #1 that I
mentioned,

I.e. not just ignore stuff like user.email, but being able to specify
where from you'd like to ignore that. Sometimes your local sysadmin is
overzealous with his /etc/gitconfig settings and you'd like to
quarantine just that, but pay attention to everything else in
~/.gitconfig, or similarly in /some/repo/.git/config ignore your usual
custom sendemail.* from ~/.gitconfig but not /etc/gitconfig, so the
semantics can't just be "clear existing".

But of course, you might say that it *should* be a syntax error because
if you rely on this feature and downgrade, you don't want to suddenly
pay attention to the sendemail.* config again.

I think that's an acceptable failure mode, and better than the syntax
error, because that's exactly what we have now, so this is similar to
e.g. the conditional include directive which was understood but just
copmletely ignored by older versions.

So we're OK with getting different config between versions with new
releases, but at all costs don't want to have new releases introduce
constructs that older gits error out on, and let's say hypothetically we
supported something like:

[user "-email"]
[user]
email = ...

Even `git config -l` on older version won't show that "user.-email", and
it's better if older tools at least understand the syntax, even though
they don't pick up on the magic.

Re: How to undo previously set configuration?

[Olaf Hering]

Am Thu, 05 Apr 2018 10:42:15 +0200
schrieb Ævar Arnfjörð Bjarmason :

> I've been meaning to work on this but haven't figured out a good syntax for 
> it (suggestions welcome!).

Just prefix the knob with something like "no." or "-" or whatever to indicate 
that it never happened.

Olaf


pgpfQgIWe0Wl7.pgp
Description: Digitale Signatur von OpenPGP