Am 15.10.2017 um 13:08 schrieb Martin Ågren: > On 15 October 2017 at 12:02, Thomas Rikl <trikl@xxxxxxxxx> wrote: >> Example: >> >> tom1 ~/emacs/spacemacs/.emacs.d $ export LANG=en_US.utf8 >> >> tom1 ~/emacs/spacemacs/.emacs.d $ git ls-remote -h >> usage: git ls-remote [--heads] [--tags] [--refs] [--upload-pack=<exec>] >> [-q | --quiet] [--exit-code] [--get-url] >> [--symref] [<repository> [<refs>...]] >> >> -q, --quiet do not print remote URL >> --upload-pack <exec> path of git-upload-pack on the remote host >> -t, --tags limit to tags >> -h, --heads limit to heads >> --refs do not show peeled tags >> --get-url take url.<base>.insteadOf into account >> --exit-code exit with exit code 2 if no matching refs are >> found >> --symref show underlying ref in addition to the object >> pointed by it >> >> tom1 ~/emacs/spacemacs/.emacs.d $ git ls-remote --head >> From https://github.com/syl20bnr/spacemacs >> 07014deead544c51fa6a826e91fe2ef05bf04323 refs/heads/develop >> 8e1af145480d53e8d32cdff2c83291889903164b refs/heads/master >> 2450b7e276634ece07b6b7ec6ca6c287af86caf3 refs/heads/release-0.101 >> 8dadfc1494544bb152e80c2a436e43bc3713b389 refs/heads/release-0.102 >> d993a021847cde2c42865bab6afa8adbb2edda0b refs/heads/release-0.103 >> 44d4525543b1f2a385142721d0cb16cd3b0be580 refs/heads/release-0.104 >> 9f9faa404e3dec3e08cc73cf7b5a0439fc309800 refs/heads/release-0.105 >> 8e1af145480d53e8d32cdff2c83291889903164b refs/heads/release-0.200 >> tom1 ~/emacs/spacemacs/.emacs.d $ git --version >> git version 2.14.2 >> >> on archlinux: Linux achse 4.13.5-1-ARCH #1 SMP PREEMPT Fri Oct 6 09:58:47 >> CEST 2017 x86_64 GNU/Linux > > The behavior you observed matches with the documentation in gitcli(7) > and is arguably correct. A lone "-h" prints the help/usage. But I would > agree that this can be confusing, especially when considering > git-ls-remote(1) on its own, without any extra knowledge about what a > lone -h should do. > > So -h and --heads can only be used interchangeably if you have other > arguments. To see this, you could, e.g., try "git ls-remote -h -h". > > Some more details. This looks like ba5f28bf7 (ls-remote: use > parse-options api, 2016-01-19). Before that, "-h" was handled internally > in builtin/ls-files.c. After that it is handled in the general > options-parsing machinery. See for example 5ad0d3d52 (parse-options: > allow -h as a short option, 2015-11-17), which explicitly wants to print > the usage-string if "-h" is given as the lone argument. > > I'm not sure which is the best way forward here, or how many other > commands could have similar pitfalls. For example, the "-h"-flag of git > grep shouldn't be able to cause this problem. The flag PARSE_OPT_NO_INTERNAL_HELP should be used to let git ls-remote fully handle -h. The same goes for git show-ref, but perhaps it's better to remove its hidden option -h by now. But stepping back a bit I wonder if the demure internal -h handler (that only speaks up when nothing else is said) is a bit too subtle. Reverting 5ad0d3d52 would make the need for PARSE_OPT_NO_INTERNAL_HELP more obvious. René
