From: Ben Knoble <ben.knoble@gmail.com>
Date: Thu, 03 Sep 2026 18:22:46 GMT
Subject: Re: [PATCH v3] var: support broken-down idents, default key, multiple args, and -z
Message-ID: <D27B3BE0-56E7-4388-9324-C16E2AAE2498@gmail.com>
In-Reply-To: <xmqqbjaecjxb.fsf@gitster.g>


> Le 3 sept. 2026 à 14:02, Junio C Hamano <gitster@pobox.com> a écrit :
> 
> "Andrew Pleeter via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> +    if (!vars.nr)
>>        usage(var_usage);
> 
> I do not know if this is friendly for a tool meant primarily for
> scripts.  "git var foo bar" would give information about foo and
> bar, "git var foo" would give informmation about foo, and it is
> natural "git var" alone would give nothing.

I believe « git var » prints usage and exits 129 today, at least on my 2.55.0.340.g8e2bf96aa5.

Lifting the limitation may be sensible, though I suspect the empty case is likely to indicate a logic error earlier in the script; either way, probably out of scope here for now?

> This matters because it is plausible to have a list of vars in a
> variable and then run "git var -z $variables | xargs -0 ..." to
> process the vars and their values.  If you barf for an empty list,
> then they need to see if they have nothing in $variable, which
> becomes more than "test -z "$variable" because people often take
> advantage of the fact that IFS is ignored to write their accumulator
> like so
> 
>    variable=" "
>    for n in ...
>    do
>        variable="$variable$n "
>    done
> 
>    case "$variable" in
>    *" "word" "*)
>        : has the word
>        ;;
>    esac
> 
> which means that $variable may not be an empty string.  It is easier
> for scripts if "git var <variable>..." did not barf when the number
> of <variable>s happens to be zero.