• Junio C Hamano's avatar
    parseopt: handle malformed --expire arguments more nicely · 8ab5aa4b
    Junio C Hamano authored
    A few commands that parse --expire=<time> command line option behave
    sillily when given nonsense input.  For example
    
        $ git prune --no-expire
        Segmentation falut
        $ git prune --expire=npw; echo $?
        129
    
    Both come from parse_opt_expiry_date_cb().
    
    The former is because the function is not prepared to see arg==NULL
    (for "--no-expire", it is a norm; "--expire" at the end of the
    command line could be made to pass NULL, if it is told that the
    argument is optional, but we don't so we do not have to worry about
    that case).
    
    The latter is because it does not check the value returned from the
    underlying parse_expiry_date().
    
    This seems to be a recent regression introduced while we attempted
    to avoid spewing the entire usage message when given a correct
    option but with an invalid value at 3bb0923f ("parse-options: do not
    show usage upon invalid option value", 2018-03-22).  Before that, we
    didn't fail silently but showed a full usage help (which arguably is
    not all that better).
    
    Also catch this error early when "git gc --prune=<expiration>" is
    misspelled by doing a dummy parsing before the main body of "gc"
    that is time consuming even begins.  Otherwise, we'd spend time to
    pack objects and then later have "git prune" first notice the error.
    Aborting "gc" in the middle that way is not harmful but is ugly and
    can be avoided.
    Helped-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    8ab5aa4b
parse-options-cb.c 5.27 KB