On Mon, Apr 29, 2024 at 03:01:55PM +1000, James Liu wrote:
> > > int advice_enabled(enum advice_type type)
> > > {
> > > - int enabled = advice_setting[type].level != ADVICE_LEVEL_DISABLED;
> > > + int enabled;
> > > +
> > > + if (getenv(GIT_NO_ADVICE))
> > > + return 0;
> >
> > Huh, I was under impression that having an environment
> > variable to control this behavior was frowned upon by
> > Junio? [1] To me, supporting such a variable would be
> > a somewhat acceptable risk, [2] but of course it's the
> > maintainer's opinion that matters most.
> >
> > [1] https://lore.kernel.org/git/xmqqfrva3k9j.fsf@gitster.g/
> > [2]
> > https://lore.kernel.org/git/462de4ec1fb1896fa7f26b3515deca57@xxxxxxxxxxx/
>
> You're correct. I saw this pattern for a few of the other global CLI
> options and followed it. I'm unsure what the best alternative for
> passing this configuration down to the `advice_enabled()` function is.
> I'd appreciate some guidance here.
You need an environment variable if you want the command-line option to
work consistently across commands that spawn external processes. E.g.:
git --no-advice fetch --all
is going to spawn fetch sub-processes under the hood. You'd want them to
respect --no-advice, too, so we either have to propagate the
command-line option or use the environment. And when you consider an
external script like git-foo that runs a bunch of underlying Git
commands, then propagating becomes too cumbersome and error-prone.
You should use git_env_bool() to avoid the confusing behavior that
GIT_NO_ADVICE=false still turns off advice. ;)
You can also drop the "NO", which helps avoid awkward double negation.
For example, if you do:
if (git_env_bool("GIT_ADVICE", 1))
return 0;
then leaving that variable unset will act as if it is set to "1", but
you can still do GIT_ADVICE=0 to suppress it.
There are some older variables (e.g., GIT_NO_REPLACE_OBJECTS) that made
this mistake and we are stuck with, but I think we should avoid it for
newer ones.
-Peff
