On Fri, Jul 01, 2016 at 12:25:39PM -0700, Junio C Hamano wrote:
> Jeff King <[email protected]> writes:
>
> > Compare to:
> >
> > if test "$GIT_PUSH_VAR_force" = true
> > ...
>
> OK. As this is a new feature, I guess it is not too bad if we tell
> users that they cannot have duplicate keys in their <key,val> data
> they ask Git to transport. They can do the key1=val1 key2=val2
> numbering themselves if that is really needed.
That was sort of my question. _Is it_ too bad or not? It's hard to say
without knowing the use cases.
I'm OK with the more flexible scheme if it's something people really
want to use. Though perhaps with your suggestion, we can have our cake
and eat it, too. If we codify the key1/key2 thing by converting:
git push --push-var=foo=one --push-var=foo=two
into:
GIT_PUSH_VAR_foo=one
GIT_PUSH_VAR_foo1=two
then a hook can either:
- just use $GIT_PUSH_VAR_foo if they only know how to handle a single
value
- handle a list like:
if test -n "$GIT_PUSH_VAR_foo"
then
# non-empty list
echo first value is $GIT_PUSH_VAR_foo
i=1
while true; do
eval "test -z \$GIT_PUSH_VAR_foo$i" && break
eval "echo value \$i is \$GIT_PUSH_VAR_foo$i"
done
fi
That's ugly, of course, but not really uglier than the parsing required
for the COUNT proposal.
I'm assuming that git actually knows about and enforces that things are
"key=value". I'm not sure how you'd get by without that (you'd have to
infer the meaning of a parameter by its position, which seems like a
recipe for mistakes and incompatibilities).
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
