git/contrib/completion, branch v2.53.0

completion: clarify support for short options and arguments

2025-12-07T01:05:49Z

The list of supported completions in the header of the file was mostly written a long time ago when Shawn added the initial version of this script in 2006. The list explicitly states that we complete "common --long-options", which implies that we do not complete not-so-common ones and single letter options (this text dates back to May 2007). Update the description to explicitly state that single-letter options are not completed. Also, document that arguments to options are completed, even for single-letter options (e.g., "git -c " offers configuration variables). The reason why we do not complete single-letter options is because it does not seem to help all that much to learn that the command takes -c, -d, -e options when "git foo -" offers these three, unlike long options that is easier to guess what they are about. Because this rationale is primarily for our developers, let's leave it out of the completion script itself, whose messages are entirely for end-users. Our developers can run "git blame" to find this commit as needed. Signed-off-by: Junio C Hamano

completion: complete some 'git log' options

2025-10-20T18:07:24Z

1. '--exclude=' option to 'git log' and 'git shortlog' are missing. Add the option to __git_log_shortlog_options. 2. The `--committer` option in `git log` requires a pattern, such as `--committer=ba`, but in `git shortlog`, specifying a pattern results in an error: “error: option `committer' takes no value.” Handle them as separate options for completion rather than a shared one. Signed-off-by: KIYOTA Fumiya Signed-off-by: Junio C Hamano

contrib/completion: install Bash completion

2025-04-22T15:26:12Z

The shell completion scripts in "contrib/completion" are being tested, but none of our build systems support installing them. This is somewhat confusing for Meson, where users can explicitly enable building these scripts via `-Dcontrib=completion`. This option only controlls whether the completions are built and tested against, where "building" is a bit of an euphemism for "copying them into the build directory". Teach both our Makefile and Meson to install our Bash completion script. For now, this is the only completion script that we're installing given that Bash completions "just work" with a canonical well-known location nowadays. Other completion scripts, like for example the one for zsh, don't have a well-known location and/or require extra steps by the user to make them available. As such, we skip installing these scripts for now, but we may do so in the future if we ever figure out a proper way to do this. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

completion: fix bugs with slashes in remote names

2025-03-24T06:03:13Z

Previously, some calls to for-each-ref passed fixed numbers of path components to strip from refs, assuming that remote names had no slashes in them. This made completions like: git push github/dseomn :com Result in: git push github/dseomn :dseomn/completion-remote-slash With this patch, it instead results in: git push github/dseomn :completion-remote-slash Signed-off-by: David Mandelberg Signed-off-by: Junio C Hamano

completion: add helper to count path components

2025-03-24T06:03:12Z

A follow-up commit will use this with for-each-ref to strip the right number of path components from refnames. Signed-off-by: David Mandelberg Signed-off-by: Junio C Hamano

Merge branch 'dk/zsh-config-completion-fix'

2025-01-21T16:44:55Z

Completion script updates for zsh * dk/zsh-config-completion-fix: completion: repair config completion for Zsh

completion: repair config completion for Zsh

2025-01-06T22:21:26Z

Commit 1e0ee4087e (completion: add and use __git_compute_first_level_config_vars_for_section, 2024-02-10) uses an indirect variable syntax that is only valid for Bash, but the Zsh completion code relies on the Bash completion code to function. Zsh supports a different indirect variable expansion using ${(P)var}, but in `emulate ksh` mode does not support Bash's ${!var}. This manifests as completing strange config options like "__git_first_level_config_vars_for_section_remote" as a choice for the command line git config set remote. Using Zsh's C-x ? _complete_debug widget with the cursor at the end of that command line captures a trace, in which we see (some details elided): +__git_complete_config_variable_name:7> __git_compute_first_level_config_vars_for_section remote +__git_compute_first_level_config_vars_for_section:7> local section=remote +__git_compute_first_level_config_vars_for_section:7> __git_compute_config_vars +__git_compute_config_vars:7> test -n $'add.ignoreErrors\nadvice.addEmbeddedRepo\nadvice.addEmptyPathspec\nadvice.addIgnoredFile[…]' +__git_compute_first_level_config_vars_for_section:7> local this_section=__git_first_level_config_vars_for_section_remote +__git_compute_first_level_config_vars_for_section:7> test -n __git_first_level_config_vars_for_section_remote +__git_complete_config_variable_name:7> local this_section=__git_first_level_config_vars_for_section_remote +__git_complete_config_variable_name:7> __gitcomp_nl_append __git_first_level_config_vars_for_section_remote remote. '' ' ' +__gitcomp_nl_append:7> __gitcomp_nl __git_first_level_config_vars_for_section_remote remote. '' ' ' +__gitcomp_nl:7> emulate -L zsh +__gitcomp_nl:7> compset -P '*[=:]' +__gitcomp_nl:7> compadd -Q -S ' ' -p remote. -- __git_first_level_config_vars_for_section_remote We perform the test for __git_compute_config_vars correctly, but the ${!this_section} references are not expanded as expected. Instead, portably expand indirect references through the new __git_indirect. Contrary to some versions you might find online [1], this version avoids echo non-portabilities [2] [3] and correctly quotes the indirect expansion after eval (so that the result is not split or globbed before being handed to printf). [1]: https://unix.stackexchange.com/a/41409/301073 [2]: https://askubuntu.com/questions/715765/mysterious-behavior-of-echo-command#comment1056038_715769 [3]: https://mywiki.wooledge.org/CatEchoLs The following demo program demonstrates how this works: b=1 indirect() { eval printf '%s' "\"\$$1\"" } f() { # Comment this out to see that it works for globals, too. Or, use # a value with spaces like '2 3 4' to see how it handles those. local b=2 local a=b test -n "$(indirect $a)" && echo nice } f When placed in a file "demo", then both bash -x demo and zsh -xc 'emulate ksh -c ". ./demo"' |& tail provide traces showing that "$(indirect $a)" produces 2 (or 1, with the global, or "2 3 4" as a single string, etc.). Signed-off-by: D. Ben Knoble Acked-by: Philippe Blain Signed-off-by: Junio C Hamano

Merge branch 'ps/build'

2024-12-16T01:54:33Z

Build procedure update plus introduction of Meson based builds. * ps/build: (24 commits) Introduce support for the Meson build system Documentation: add comparison of build systems t: allow overriding build dir t: better support for out-of-tree builds Documentation: extract script to generate a list of mergetools Documentation: teach "cmd-list.perl" about out-of-tree builds Documentation: allow sourcing generated includes from separate dir Makefile: simplify building of templates Makefile: write absolute program path into bin-wrappers Makefile: allow "bin-wrappers/" directory to exist Makefile: refactor generators to be PWD-independent Makefile: extract script to generate gitweb.js Makefile: extract script to generate gitweb.cgi Makefile: extract script to massage Python scripts Makefile: extract script to massage Shell scripts Makefile: use "generate-perl.sh" to massage Perl library Makefile: extract script to massage Perl scripts Makefile: consistently use PERL_PATH Makefile: generate doc versions via GIT-VERSION-GEN Makefile: generate "git.rc" via GIT-VERSION-GEN ...

Introduce support for the Meson build system

2024-12-06T22:52:14Z

Introduce support for the Meson build system, a "modern" meta build system that supports many different platforms, including Linux, macOS, Windows and BSDs. Meson supports different backends, including Ninja, Xcode and Microsoft Visual Studio. Several common IDEs provide an integration with it. The biggest contender compared to Meson is probably CMake as outlined in our "Documentation/technical/build-systems.txt" file. Based on my own personal experience from working with both build systems extensively I strongly favor Meson over CMake. In my opinion, it feels significantly easier to use with a syntax that feels more like a "real" programming language. The second big reason is that Meson supports Rust natively, which may prove to be important given that the project may pick up Rust as another language eventually. Using Meson is rather straight-forward. An example: ``` # Meson uses out-of-tree builds. You can set up multiple build # directories, how you name them is completely up to you. $ mkdir build $ cd build $ meson setup .. -Dprefix=/tmp/git-installation # Build the project. This also provides several other targets like e.g. `install` or `test`. $ ninja # Meson has been wired up to support execution of our test suites. # Both our unit tests and our integration tests are supported. # Running `meson test` without any arguments will execute all tests, # but the syntax supports globbing to select only some tests. $ meson test 't-*' # Execute single test interactively to allow for debugging. $ meson test 't0000-*' --interactive --test-args=-ix ``` The build instructions have been successfully tested on the following systems, tests are passing: - Apple macOS 10.15. - FreeBSD 14.1. - NixOS 24.11. - OpenBSD 7.6. - Ubuntu 24.04. - Windows 10 with Cygwin. - Windows 10 with MinGW64, except for t9700, which is also broken with our Makefile. - Windows 10 with Visual Studio 2022 toolchain, using the Native Tools Command Prompt with `meson setup --vsenv`. Tests pass, except for t9700. - Windows 10 with Visual Studio 2022 solution, using the Native Tools Command Prompt with `meson setup --backend vs2022`. Tests pass, except for t9700. - Windows 10 with VS Code, using the Meson plug-in. It is expected that there will still be rough edges in the current version. If this patch lands the expectation is that it will coexist with our other build systems for a while. Like this, distributions can slowly migrate over to Meson and report any findings they have to us such that we can continue to iterate. A potential cutoff date for other build systems may be Git 3.0. Some notes: - The installed distribution is structured somewhat differently than how it used to be the case. All of our binaries are installed into `$libexec/git-core`, while all binaries part of `$bindir` are now symbolic links pointing to the former. This rule is consistent in itself and thus easier to reason about. - We do not install dashed binaries into `$libexec/git-core` anymore, so there won't e.g. be a symlink for git-add(1). These are not required by modern Git and there isn't really much of a use case for those anymore. By not installing those symlinks we thus start the deprecation of this layout. - We're targeting Meson 1.3.0, which has been released relatively recently November 2023. The only feature we use from that version is `fs.relative_to()`, which we could replace if necessary. If so, we could start to target Meson 1.0.0 and newer, released in December 2022. - The whole build instructions count around 3300 lines, half of which is listing all of our code and test files. Our Makefiles are around 5000 lines, autoconf adds another 1300 lines. CMake in comparison has only 1200 linescode, but it avoids listing individual files and does not wire up auto-configuration as extensively as the Meson instructions do. - We bundle a set of subproject wrappers for curl, expat, openssl, pcre2 and zlib. This allows developers to build Git without these dependencies preinstalled, and Meson will fetch and build them automatically. This is especially helpful on Windows. Helped-by: Eli Schwartz Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

completion: complete '--tool-help' in 'git mergetool'

2024-11-25T02:59:18Z

Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano