Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Dec 7, 2010
  1. @jrn @gitster

    parse-options: make resuming easier after PARSE_OPT_STOP_AT_NON_OPTION

    jrn authored gitster committed
    Introduce a PARSE_OPT_NON_OPTION state, so parse_option_step()
    callers can easily distinguish between non-options and other
    reasons for option parsing termination (like "--").
    
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @jrn @gitster

    parse-options: allow git commands to invent new option types

    jrn authored gitster committed
    parse-options provides a variety of option behaviors, including
    OPTION_CALLBACK, which should take care of just about any sane
    behavior.  All supported behaviors obey the following constraint:
    
     A --foo option can only accept (and base its behavior on)
     one argument, which would be the following command-line
     argument in the "unsticked" form.
    
    Alas, some existing git commands have options that do not obey that
    constraint.  For example, update-index --cacheinfo takes three
    arguments, and update-index --resolve takes all later parameters as
    arguments.
    
    Introduces an OPTION_LOWLEVEL_CALLBACK backdoor to parse-options so
    such option types can be supported without tempting inventors of other
    commands through mention in the public API.  Commands can set the
    callback field to a function accepting three arguments: the option
    parsing context, the option itself, and a flag indicating whether the
    the option was negated.  When the option is encountered, that function
    is called to take over from get_value().  The return value should be
    zero for success, -1 for usage errors.
    
    Thanks to Stephen Boyd for API guidance.
    
    Improved-by: Stephen Boyd <bebarino@gmail.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @jrn @gitster

    parse-options: never suppress arghelp if LITERAL_ARGHELP is set

    jrn authored gitster committed
    The PARSE_OPT_LITERAL_ARGHELP flag allows a program to override the
    standard "<argument> for mandatory, [argument] for optional" markup in
    its help message.  Extend it to override the usual "no text for
    disallowed", too (for the PARSE_OPT_NOARG | PARSE_OPT_LITERAL_ARGHELP
    case, which was previously meaningless), to be more intuitive.
    
    The motivation is to allow update-index to correctly advertise
    
    	--cacheinfo <mode> <object> <path>
    	                      add the specified entry to the index
    
    while abusing PARSE_OPT_NOARG to disallow the "sticked form"
    
    	--cacheinfo=<mode> <object> <path>
    
    Noticed-by: Stephen Boyd <bebarino@gmail.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  4. @jrn @gitster

    parse-options: sanity check PARSE_OPT_NOARG flag

    jrn authored gitster committed
    Some option types cannot use an argument --- boolean options that
    would set a bit or flag or increment a counter, for example.  If
    configured in the flag word to accept an argument anyway, the result
    is an argument that is advertised in "program -h" output only to be
    rejected by parse-options::get_value.
    
    Luckily all current users of these option types use PARSE_OPT_NOARG
    and do not use PARSE_OPT_OPTARG.  Add a check to ensure that that
    remains true.  The check is run once for each invocation of
    parse_option_start().
    
    Improved-by: Stephen Boyd <bebarino@gmail.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  5. @jrn @gitster

    parse-options: move NODASH sanity checks to parse_options_check

    jrn authored gitster committed
    A dashless switch (like '(' passed to 'git grep') cannot be negated,
    cannot be attached to an argument, and cannot have a long form.
    Currently parse-options runs the related sanity checks when the
    dashless option is used; better to always check them at the start of
    option parsing, so mistakes can be caught more quickly.
    
    The error message at the new call site is less specific about the
    nature of the error, for simplicity.  On the other hand, it prints
    which switch was problematic.  Before:
    
    	fatal: BUG: dashless options can't be long
    
    After:
    
    	error: BUG: switch '(' uses feature not supported for dashless options
    
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  6. @jrn @gitster

    parse-options: clearer reporting of API misuse

    jrn authored gitster committed
    The PARSE_OPT_LASTARG_DEFAULT flag is meant for options like
    --contains that (1) traditionally had a mandatory argument and
    (2) have some better behavior to use when appearing in the final
    position.  It makes no sense to combine this with OPTARG, so ever
    since v1.6.4-rc0~71 (parse-options: add parse_options_check to
    validate option specs, 2009-07-09) this mistake is flagged with
    
    	error: `--option` uses incompatible flags LASTARG_DEFAULT and OPTARG
    
    and an exit status representing an error in commandline usage.
    
    Unfortunately that which might confuse scripters calling such an
    erroneous program into thinking the _script_ contains an error.
    Clarify that it is an internal error by dying with a message beginning
    "error: BUG: ..." and status 128.
    
    While at it, clean up parse_options_check to prepare for more checks.
    
    Long term, it would be nicer to make such checks happen at compile
    time.
    
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Something went wrong with that request. Please try again.