Nicolas Vigier wrote:
> I'm thinking about a patch to add the following two options to rev-parse :
>
> --sticked-opt-args::
> Only meaningful in --parseopt mode. Tells the options parser to
> output options with optional arguments in sticked form. The
> default is to output them
On Wed, Oct 16, 2013 at 02:40:07PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... But what is the normalized form for an
> > optional argument? It either needs to be consistently "sticked" or
> > "unsticked", either:
> >
> > set -- -S '' -- ;# default
> > set -- -S 'foo' --
Jeff King writes:
> ... But what is the normalized form for an
> optional argument? It either needs to be consistently "sticked" or
> "unsticked", either:
>
> set -- -S '' -- ;# default
> set -- -S 'foo' -- ;# not default
>
> or
>
> set -- -S --;# default
> set -- -Sfoo -- ;# not
On Tue, 15 Oct 2013, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
> > You just made these two that the user clearly meant to express two
> > different things indistinguishable.
> >
> > opt.sh -S
> > opt.sh -S ''
> [...]
> > And that is exactly why gitcli.txt tells users to use the '
On Wed, 16 Oct 2013, Johannes Sixt wrote:
> Am 10/16/2013 1:57, schrieb Jonathan Nieder:
> > Junio C Hamano wrote:
> >
> >> You just made these two that the user clearly meant to express two
> >> different things indistinguishable.
> >>
> >>opt.sh -S
> >> opt.sh -S ''
> > [...]
> >> And
On Wed, Oct 16, 2013 at 09:04:32AM +0200, Johannes Sixt wrote:
> > Yes, another possibility in that vein would be to teach rev-parse
> > --parseopt an OPTIONS_LONG_STICKED output format, and then parse with
>
> Aren't you people trying to solve something that can't besolved? What does
>
> git
Am 10/16/2013 1:57, schrieb Jonathan Nieder:
> Junio C Hamano wrote:
>
>> You just made these two that the user clearly meant to express two
>> different things indistinguishable.
>>
>> opt.sh -S
>> opt.sh -S ''
> [...]
>> And that is exactly why gitcli.txt tells users to use the 'stick
Junio C Hamano wrote:
> You just made these two that the user clearly meant to express two
> different things indistinguishable.
>
> opt.sh -S
> opt.sh -S ''
[...]
> And that is exactly why gitcli.txt tells users to use the 'sticked'
> form, and ends the bullet point with:
>
>An op
On Tue, 15 Oct 2013, Jonathan Nieder wrote:
> Nicolas Vigier wrote:
>
> > $ cat /tmp/opt.sh
> > #!/bin/sh
> > OPTIONS_SPEC="\
> > git [options]
> > --
> > q,quiet be quiet
> > S,gpg-sign? GPG-sign commit"
> > echo "$OPTIONS_SPEC" | git rev-parse --parseopt $parseopt_ex
On Tue, 15 Oct 2013, Junio C Hamano wrote:
> Nicolas Vigier writes:
>
> > git rev-parse --parseopt does not allow us to see the difference
> > between an option with an optional argument starting with a dash, and an
> > option with an unset optional argument followed by an other option.
> >
> >
Jonathan Nieder writes:
> Nicolas Vigier wrote:
>
>> $ cat /tmp/opt.sh
>> #!/bin/sh
>> OPTIONS_SPEC="\
>> git [options]
>> --
>> q,quiet be quiet
>> S,gpg-sign? GPG-sign commit"
>> echo "$OPTIONS_SPEC" | git rev-parse --parseopt $parseopt_extra -- "$@"
>>
>> Then the f
Nicolas Vigier wrote:
> $ cat /tmp/opt.sh
> #!/bin/sh
> OPTIONS_SPEC="\
> git [options]
> --
> q,quiet be quiet
> S,gpg-sign? GPG-sign commit"
> echo "$OPTIONS_SPEC" | git rev-parse --parseopt $parseopt_extra -- "$@"
>
> Then the following two commands give us the same
Nicolas Vigier writes:
> git rev-parse --parseopt does not allow us to see the difference
> between an option with an optional argument starting with a dash, and an
> option with an unset optional argument followed by an other option.
>
> If I use this script :
>
> $ cat /tmp/opt.sh
> #!/bin/
git rev-parse --parseopt does not allow us to see the difference
between an option with an optional argument starting with a dash, and an
option with an unset optional argument followed by an other option.
If I use this script :
$ cat /tmp/opt.sh
#!/bin/sh
OPTIONS_SPEC="\
git [options]
14 matches
Mail list logo