path: root/Documentation
diff options
authorJunio C Hamano <>2018-04-21 03:13:13 (GMT)
committerJunio C Hamano <>2018-04-23 13:36:59 (GMT)
commit8ab5aa4bd8e218b9658dbdd7f5bfcaa512f607dc (patch)
treebf1b1a8099a7d66616e347e356f3d761b393aaf1 /Documentation
parent96913c9df65129554b23e3a895f353335b78bda7 (diff)
parseopt: handle malformed --expire arguments more nicely
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: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions