Re: [PATCH 1/4] push options: {pre,post}-receive hook learns about push options

From: Jeff King <peff@peff.net>
Date: Jul 1, 2016, 19:39 UTC
Message-ID: <20160701193909.GA23141@sigill.intra.peff.net>
In-Reply-To: <xmqqr3bdxirw.fsf@gitster.mtv.corp.google.com>

On Fri, Jul 01, 2016 at 12:25:39PM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> Jeff King <peff@peff.net> 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