git/parse-options.c, branch v2.21.4

Merge branch 'nd/indentation-fix'

2019-01-14T23:29:32Z

Code cleanup. * nd/indentation-fix: Indent code with TABs

Merge branch 'nd/i18n'

2019-01-04T21:33:31Z

More _("i18n") markings. * nd/i18n: fsck: mark strings for translation fsck: reduce word legos to help i18n parse-options.c: mark more strings for translation parse-options.c: turn some die() to BUG() parse-options: replace opterror() with optname() repack: mark more strings for translation remote.c: mark messages for translation remote.c: turn some error() or die() to BUG() reflog: mark strings for translation read-cache.c: add missing colon separators read-cache.c: mark more strings for translation read-cache.c: turn die("internal error") to BUG() attr.c: mark more string for translation archive.c: mark more strings for translation alias.c: mark split_cmdline_strerror() strings for translation git.c: mark more strings for translation

Merge branch 'nd/show-gitcomp-compilation-fix' into maint

2018-12-15T03:24:33Z

Portability fix for a recent update to parse-options API. * nd/show-gitcomp-compilation-fix: parse-options: fix SunCC compiler warning

parse-options: fix SunCC compiler warning

2018-12-12T08:21:33Z

The compiler reports this because show_gitcomp() never actually returns a value: "parse-options.c", line 520: warning: Function has no return statement : show_gitcomp We could shut the compiler up. But instead let's not bury exit() too deep. Do the same as internal -h handling, return a special error code and handle the exit() in parse_options() (and other parse_options_step() callers) instead. Reported-by: Ævar Arnfjörð Bjarmason Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Indent code with TABs

2018-12-09T03:37:32Z

We indent with TABs and sometimes for fine alignment, TABs followed by spaces, but never all spaces (unless the indentation is less than 8 columns). Indenting with spaces slips through in some places. Fix them. Imported code and compat/ are left alone on purpose. The former should remain as close as upstream as possible. The latter pretty much has separate maintainers, it's up to them to decide. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

parse-options.c: mark more strings for translation

2018-11-12T05:47:10Z

One error is updated to start with lowercase to be consistent with the rest. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

parse-options.c: turn some die() to BUG()

2018-11-12T05:47:09Z

These two strings are clearly not for the user to see. Reduce the violence in one string while at there. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

parse-options: replace opterror() with optname()

2018-11-12T05:47:09Z

Introduce optname() that does the early half of original opterror() to come up with the name of the option reported back to the user, and use it to kill opterror(). The callers of opterror() now directly call error() using the string returned by opterror() instead. There are a few issues with opterror() - it tries to assemble an English sentence from pieces. This is not great for translators because we give them pieces instead of a full sentence. - It's a wrapper around error() and needs some hack to let the compiler know it always returns -1. - Since it takes a string instead of printf format, one call site has to assemble the string manually before passing to it. Using error() directly solves the second and third problems. It kind helps the first problem as well because "%s does foo" does give a translator a full sentence in a sense and let them reorder if needed. But it has limitations, if the subject part has to change based on the rest of the sentence, that language is screwed. This is also why I try to avoid calling optname() when 'flags' is known in advance. Mark of these strings for translation as well while at there. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'rs/parse-opt-lithelp'

2018-08-17T20:09:56Z

The parse-options machinery learned to refrain from enclosing placeholder string inside a "" pair automatically without PARSE_OPT_LITERAL_ARGHELP. Existing help text for option arguments that are not formatted correctly have been identified and fixed. * rs/parse-opt-lithelp: parse-options: automatically infer PARSE_OPT_LITERAL_ARGHELP shortlog: correct option help for -w send-pack: specify --force-with-lease argument help explicitly pack-objects: specify --index-version argument help explicitly difftool: remove angular brackets from argument help add, update-index: fix --chmod argument help push: use PARSE_OPT_LITERAL_ARGHELP instead of unbalanced brackets

parse-options: automatically infer PARSE_OPT_LITERAL_ARGHELP

2018-08-03T15:36:20Z

Parseopt wraps argument help strings in a pair of angular brackets by default, to tell users that they need to replace it with an actual value. This is useful in most cases, because most option arguments are indeed single values of a certain type. The option PARSE_OPT_LITERAL_ARGHELP needs to be used in option definitions with arguments that have multiple parts or are literal strings. Stop adding these angular brackets if special characters are present, as they indicate that we don't deal with a simple placeholder. This simplifies the code a bit and makes defining special options slightly easier. Remove the flag PARSE_OPT_LITERAL_ARGHELP in the cases where the new and more cautious handling suffices. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano