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 'sticked'
form, 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 commit
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 that is exactly why
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 'sticked'
Jeff King p...@peff.net 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 Wed, Oct 16, 2013 at 02:40:07PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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' -- ;#
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 in
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]
Nicolas Vigier bo...@mars-attacks.org 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
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 result :
$
Jonathan Nieder jrnie...@gmail.com 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 following
On Tue, 15 Oct 2013, Junio C Hamano wrote:
Nicolas Vigier bo...@mars-attacks.org 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
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_extra -- $@
Then
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 option
14 matches
Mail list logo
