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. Martin
