summaryrefslogtreecommitdiff
path: root/Documentation/howto/recover-corrupted-blob-object.txt
diff options
context:
space:
mode:
authorLibravatar Ævar Arnfjörð Bjarmason <avarab@gmail.com>2018-08-02 00:31:33 +0200
committerLibravatar Junio C Hamano <gitster@pobox.com>2018-08-03 08:31:28 -0700
commitc67318ecb6ddef6b9ecf59a422c4a282594e602d (patch)
tree24ecf22f4fc3e37e112bebf610b83a4993d7ed13 /Documentation/howto/recover-corrupted-blob-object.txt
parentGit 2.16.4 (diff)
downloadtgif-c67318ecb6ddef6b9ecf59a422c4a282594e602d.tar.xz
push: use PARSE_OPT_LITERAL_ARGHELP instead of unbalanced brackets
The option help text for the force-with-lease option to "git push" reads like this: $ git push -h 2>&1 | grep -e force-with-lease --force-with-lease[=<refname>:<expect>] which comes from having N_("refname>:<expect") as the argument help text in the source code, with an aparent lack of "<" and ">" at both ends. It turns out that parse-options machinery takes the whole string and encloses it inside a pair of "<>", to make it easier for majority cases that uses a single token placeholder. The help string was written in a funnily unbalanced way knowing that the end result would balance out, by somebody who forgot the presence of PARSE_OPT_LITERAL_ARGHELP, which is the escape hatch mechanism designed to help such a case. We just should use the official escape hatch instead. Because ":<expect>" part can be omitted to ask Git to guess, it may be more correct to spell it as "<refname>[:<expect>]", but that is not the focus of this topic. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/howto/recover-corrupted-blob-object.txt')
0 files changed, 0 insertions, 0 deletions