summaryrefslogtreecommitdiff
path: root/contrib/completion/git-completion.bash
AgeCommit message (Collapse)AuthorFilesLines
2021-10-29Merge branch 're/completion-fix-test-equality'Libravatar Junio C Hamano1-1/+1
Fix long-standing shell syntax error in the completion script. * re/completion-fix-test-equality: completion: fix incorrect bash/zsh string equality check
2021-10-28completion: fix incorrect bash/zsh string equality checkLibravatar Robert Estelle1-1/+1
In the basic `[`/`test` command, the string equality operator is a single `=`. The `==` operator is only available in `[[`, which is a bash-ism also supported by zsh. This mix-up was causing the following completion error in zsh: > __git_ls_files_helper:7: = not found (That message refers to the extraneous symbol in `==` ← `=`). This updates that comparison to use a single `=` inside the basic `[ … ]` test conditional. Although this fix is inconsistent with the other comparisons in this file, which use `[[ … == … ]]`, and the two expressions are functionally identical in this context, that approach was rejected due to a preference for `[`. Signed-off-by: Robert Estelle <robertestelle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18Merge branch 'js/retire-preserve-merges'Libravatar Junio C Hamano1-1/+1
The "--preserve-merges" option of "git rebase" has been removed. * js/retire-preserve-merges: sequencer: restrict scope of a formerly public function rebase: remove a no-longer-used function rebase: stop mentioning the -p option in comments rebase: remove obsolete code comment rebase: drop the internal `rebase--interactive` command git-svn: drop support for `--preserve-merges` rebase: drop support for `--preserve-merges` pull: remove support for `--rebase=preserve` tests: stop testing `git rebase --preserve-merges` remote: warn about unhandled branch.<name>.rebase values t5520: do not use `pull.rebase=preserve`
2021-10-12Merge branch 'fc/completion-updates' into maintLibravatar Junio C Hamano1-7/+7
Command line completion updates. * fc/completion-updates: completion: bash: add correct suffix in variables completion: bash: fix for multiple dash commands completion: bash: fix for suboptions with value completion: bash: fix prefix detection in branch.*
2021-09-23help / completion: make "git help" do the hard workLibravatar Ævar Arnfjörð Bjarmason1-11/+10
The "help" builtin has been able to emit configuration variables since e17ca926371 (completion: drop the hard coded list of config vars, 2018-05-26), but it hasn't produced exactly the format the completion script wanted. Let's do that. We got partway there in 2675ea1cc0f (completion: use 'sort -u' to deduplicate config variable names, 2019-08-13) and d9438873c4d (completion: deduplicate configuration sections, 2019-08-13), but after both we still needed some sorting, de-duplicating and awk post-processing of the list. We can instead simply do the relevant parsing ourselves (we were doing most of it already), and call string_list_remove_duplicates() after already sorting the list, so the caller doesn't need to invoke "sort -u". The "--config-for-completion" output is the same as before after being passed through "sort -u". Then add a new "--config-sections-for-completion" option. Under that output we'll emit config sections like "alias" (instead of "alias." in the --config-for-completion output). We need to be careful to leave the "--config-for-completion" option compatible with users git, but are still running a shell with an older git-completion.bash. If we e.g. changed the option name they'd see messages about git-completion.bash being unable to find the "--config-for-completion" option. Such backwards compatibility isn't something we should bend over backwards for, it's only helping users who: * Upgrade git * Are in an old shell * The git-completion.bash in that shell hasn't cached the old "--config-for-completion" output already. But since it's easy in this case to retain compatibility, let's do it, the older versions of git-completion.bash won't care that the input they get doesn't change after a "sort -u". While we're at it let's make "--config-for-completion" die if there's anything left over in "argc", and do the same in the new "--config-sections-for-completion" option. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-07pull: remove support for `--rebase=preserve`Libravatar Johannes Schindelin1-1/+1
In preparation for `git-rebase--preserve-merges.sh` entering its after life, we remove this (deprecated) option that would still rely on it. To help users transition who still did not receive the memo about the deprecation, we offer a helpful error message instead of throwing our hands in the air and saying that we don't know that option, never heard of it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-03Merge branch 'fc/completion-updates'Libravatar Junio C Hamano1-7/+7
Command line completion updates. * fc/completion-updates: completion: bash: add correct suffix in variables completion: bash: fix for multiple dash commands completion: bash: fix for suboptions with value completion: bash: fix prefix detection in branch.*
2021-08-18completion: bash: add correct suffix in variablesLibravatar Felipe Contreras1-3/+3
__gitcomp automatically adds a suffix, but __gitcomp_nl and others don't, we need to specify a space by default. Can be tested with: git config branch.autoSetupMe<tab> This fix only works for versions of bash greater than 4.0, before that "local sfx" creates an empty string, therefore the unset expansion doesn't work. The same happens in zsh. Therefore we don't add the test for that for now. The correct fix for all shells requires semantic changes in __gitcomp, but that can be done later. Cc: SZEDER Gábor <szeder.dev@gmail.com> Tested-by: David Aguilar <davvid@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-18completion: bash: fix for multiple dash commandsLibravatar Felipe Contreras1-1/+1
Otherwise options of commands like 'for-each-ref' are not completed. Tested-by: David Aguilar <davvid@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-18completion: bash: fix for suboptions with valueLibravatar Felipe Contreras1-1/+1
We need to ignore options that don't start with -- as well. Depending on the value of COMP_WORDBREAKS the last word could be duplicated otherwise. Can be tested with: git merge -X diff-algorithm=<tab> Tested-by: David Aguilar <davvid@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-18completion: bash: fix prefix detection in branch.*Libravatar Felipe Contreras1-2/+2
Otherwise we are completely ignoring the --cur argument. The issue can be tested with: git clone --config=branch.<tab> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Tested-by: David Aguilar <davvid@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-08Merge branch 'fw/complete-cmd-idx-fix'Libravatar Junio C Hamano1-0/+1
Recent update to completion script (in contrib/) broke those who use the __git_complete helper to define completion to their custom command. * fw/complete-cmd-idx-fix: completion: bash: fix late declaration of __git_cmd_idx
2021-07-08Merge branch 'tb/complete-diff-anchored'Libravatar Junio C Hamano1-0/+1
The command line completion (in contrib/) learned that "git diff" takes the "--anchored" option. * tb/complete-diff-anchored: completion: add --anchored to diff's options
2021-06-19completion: bash: fix late declaration of __git_cmd_idxLibravatar Fabian Wermelinger1-0/+1
A recent update to contrib/completion/git-completion.bash causes bash to fail auto complete custom commands that are wrapped with __git_func_wrap. Declaring __git_cmd_idx=0 inside __git_func_wrap resolves the issue. Signed-off-by: Fabian Wermelinger <fabianw@mavt.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-02contrib/completion: fix zsh completion regression from 59d85a2a05Libravatar David Aguilar1-1/+1
A recent change to make git-completion.bash use $__git_cmd_idx in more places broke a number of completions on zsh because it modified __git_main but did not update __git_zsh_main. Notably, completions for "add", "branch", "mv" and "push" were broken as a result of this change. In addition to the undefined variable usage, "git mv <tab>" also prints the following error: __git_count_arguments:7: bad math expression: operand expected at `"1"' _git_mv:[:7: unknown condition: -gt Remove the quotes around $__git_cmd_idx in __git_count_arguments and set __git_cmd_idx=1 early in __git_zsh_main to fix the regressions from 59d85a2a05. This was tested on zsh 5.7.1 (x86_64-apple-darwin19.0). Suggested-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: David Aguilar <davvid@gmail.com> Acked-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-31completion: add --anchored to diff's optionsLibravatar Thomas Braun1-0/+1
This flag was introduced in 2477ab2e (diff: support anchoring line(s), 2017-11-27) but back then, the bash completion script did not learn about the new flag. Add it. Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-16Merge branch 'dd/mailinfo-quoted-cr'Libravatar Junio C Hamano1-0/+5
"git mailinfo" (hence "git am") learned the "--quoted-cr" option to control how lines ending with CRLF wrapped in base64 or qp are handled. * dd/mailinfo-quoted-cr: am: learn to process quoted lines that ends with CRLF mailinfo: allow stripping quoted CR without warning mailinfo: allow squelching quoted CRLF warning mailinfo: warn if CRLF found in decoded base64/QP email mailinfo: stop parsing options manually mailinfo: load default metainfo_charset lazily
2021-05-10am: learn to process quoted lines that ends with CRLFLibravatar Đoàn Trần Công Danh1-0/+5
In previous changes, mailinfo has learnt to process lines that decoded from base64 or quoted-printable, and ends with CRLF. Let's teach "am" that new trick, too. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-07Merge branch 'si/zsh-complete-comment-fix'Libravatar Junio C Hamano1-2/+3
Portability fix for command line completion script (in contrib/). * si/zsh-complete-comment-fix: work around zsh comment in __git_complete_worktree_paths
2021-05-07Merge branch 'dl/complete-stash-updates'Libravatar Junio C Hamano1-47/+51
Further update the command line completion (in contrib/) for "git stash". * dl/complete-stash-updates: git-completion.bash: consolidate cases in _git_stash() git-completion.bash: use $__git_cmd_idx in more places git-completion.bash: rename to $__git_cmd_idx git-completion.bash: separate some commands onto their own line
2021-05-07Merge branch 'dl/complete-stash'Libravatar Junio C Hamano1-62/+60
The command line completion (in contrib/) for "git stash" has been updated. * dl/complete-stash: git-completion.bash: use __gitcomp_builtin() in _git_stash() git-completion.bash: extract from else in _git_stash() git-completion.bash: pass $__git_subcommand_idx from __git_main()
2021-05-04work around zsh comment in __git_complete_worktree_pathsLibravatar Sardorbek Imomaliev1-2/+3
[PATCH]: contrib/completion/git-completion.bash, there is a construct where comment lines are placed between the command that is on the upstream of a pipe and the command that is on the downstream of a pipe in __git_complete_worktree_paths function. Unfortunately, this script is also used by Zsh completion, but Zsh mishandles this construct when "interactive_comments" option is not set (by default it is off on macOS), resulting in a breakage: $ git worktree remove [TAB] $ git worktree remove __git_complete_worktree_paths:7: command not found: # Move the comment, even though it explains what happens on the downstream of the pipe and logically belongs where it is right now, before the entire pipeline, to work around this problem. Signed-off-by: Sardorbek Imomaliev <sardorbek.imomaliev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-30Merge branch 'vs/completion-with-set-u'Libravatar Junio C Hamano1-1/+1
Effort to make the command line completion (in contrib/) safe with "set -u" continues. * vs/completion-with-set-u: completion: avoid aliased command lookup error in nounset mode
2021-04-27git-completion.bash: consolidate cases in _git_stash()Libravatar Denton Liu1-19/+2
The $subcommand case statement in _git_stash() is quite repetitive. Consolidate the cases together into one catch-all case to reduce the repetition. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-27git-completion.bash: use $__git_cmd_idx in more placesLibravatar Denton Liu1-12/+14
With the introduction of the $__git_cmd_idx variable in e94fb44042 (git-completion.bash: pass $__git_subcommand_idx from __git_main(), 2021-03-24), completion functions were able to know the index at which the git command is listed, allowing them to skip options that are given to the underlying git itself, not the corresponding command (e.g. `-C asdf` in `git -C asdf branch`). While most of the changes here are self-explanatory, some bear further explanation. For the __git_find_on_cmdline() and __git_find_last_on_cmdline() pair of functions, these functions are only ever called in the context of a git command completion function. These functions will only care about words after the command so we can safely ignore the words before this. For _git_worktree(), this change is technically a no-op (once the __git_find_last_on_cmdline change is also applied). It was in poor style to have hard-coded on the index right after `worktree`. In case `git worktree` were to ever learn to accept options, the current situation would be inflexible. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-27git-completion.bash: rename to $__git_cmd_idxLibravatar Denton Liu1-10/+10
In e94fb44042 (git-completion.bash: pass $__git_subcommand_idx from __git_main(), 2021-03-24), the $__git_subcommand_idx variable was introduced. Naming it after the index of the subcommand is needlessly confusing as, when this variable is used, it is in the completion functions for commands (e.g. _git_remote()) where for `git remote add`, the `remote` is referred to as the command and `add` is referred to as the subcommand. Rename this variable so that it's obvious it's about git commands. While we're at it, shorten up its name so that it's still readable without being a handful to type. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-20git-completion.bash: separate some commands onto their own lineLibravatar Denton Liu1-9/+28
In e94fb44042 (git-completion.bash: pass $__git_subcommand_idx from __git_main(), 2021-03-24), a line was introduced which contained multiple statements. This is difficult to read so break it into multiple lines. While we're at it, follow this convention for the rest of the __git_main() and break up lines that contain multiple statements. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-16completion: avoid aliased command lookup error in nounset modeLibravatar Ville Skyttä1-1/+1
Aliased command lookup accesses the `list` variable before it has been set, causing an error in "nounset" mode. Initialize to an empty string to avoid that. $ git nonexistent-command <Tab>bash: list: unbound variable Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-15Merge branch 'ab/complete-cherry-pick-head'Libravatar Junio C Hamano1-1/+1
The command line completion (in contrib/) has learned that CHERRY_PICK_HEAD is a possible pseudo-ref. * ab/complete-cherry-pick-head: bash completion: complete CHERRY_PICK_HEAD
2021-04-13Merge branch 'vs/completion-with-set-u'Libravatar Junio C Hamano1-3/+3
The command-line completion script (in contrib/) had a couple of references that would have given a warning under the "-u" (nounset) option. * vs/completion-with-set-u: completion: audit and guard $GIT_* against unset use
2021-04-08completion: audit and guard $GIT_* against unset useLibravatar Ville Skyttä1-3/+3
$GIT_COMPLETION_SHOW_ALL and $GIT_TESTING_ALL_COMMAND_LIST were used without guarding against them being unset, causing errors in nounset (set -u) mode. No other nounset-unsafe $GIT_* usages were found. While at it, remove a superfluous (duplicate) unset guard from $GIT_DIR in __git_find_repo_path. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-07bash completion: complete CHERRY_PICK_HEADLibravatar Ævar Arnfjörð Bjarmason1-1/+1
When e.g. in a failed cherry pick we did not recognize CHERRY_PICK_HEAD as we do e.g. REBASE_HEAD in a failed rebase let's rectify that. When REBASE_HEAD was added in fbd7a232370 (rebase: introduce and use pseudo-ref REBASE_HEAD, 2018-02-11) a completion was added for it, but no corresponding completion existed for CHERRY_PICK_HEAD added in d7e5c0cbfb0 (Introduce CHERRY_PICK_HEAD, 2011-02-19). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-24git-completion.bash: use __gitcomp_builtin() in _git_stash()Libravatar Denton Liu1-22/+20
The completion for 'git stash' has not changed in a major way since it was converted from shell script to builtin. Now that it's a builtin, we can take advantage of the groundwork laid out by parse-options and use the generated options. Rewrite _git_stash() to take use __gitcomp_builtin() to generate completions for subcommands. The main `git stash` command does not take any arguments directly. If no subcommand is given, it automatically defaults to `git stash push`. This means that we can simplify the logic for when no subcommands have been given yet. We only have to offer subcommand completions when we're completing a non-option after "stash". One area that this patch could improve upon is that the `git stash list` command accepts log-options. It would be nice if the completion for this were unified with that of _git_log() and _git_show() which would allow completions to be provided for options such as `--pretty` but that is outside the scope of this patch. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-24git-completion.bash: extract from else in _git_stash()Libravatar Denton Liu1-36/+37
To save a level of indentation, perform an early return in the "if" arm so we can move the "else" code out of the block. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-24git-completion.bash: pass $__git_subcommand_idx from __git_main()Libravatar Denton Liu1-12/+11
Many completion functions perform hardcoded comparisons with $cword. This fails in the case where the main git command is given arguments (e.g. `git -C . bundle<TAB>` would fail to complete its subcommands). Even _git_worktree(), which uses __git_find_on_cmdline(), could still fail. With something like `git -C add worktree move<TAB>`, the subcommand would be incorrectly identified as "add" instead of "move". Assign $__git_subcommand_idx in __git_main(), where the git subcommand is actually found and the corresponding completion function is called. Use this variable to replace hardcoded comparisons with $cword. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-22Merge branch 'dl/stash-show-untracked'Libravatar Junio C Hamano1-1/+1
"git stash show" learned to optionally show untracked part of the stash. * dl/stash-show-untracked: stash show: learn stash.showIncludeUntracked stash show: teach --include-untracked and --only-untracked
2021-03-05stash show: teach --include-untracked and --only-untrackedLibravatar Denton Liu1-1/+1
Stash entries can be made with untracked files via `git stash push --include-untracked`. However, because the untracked files are stored in the third parent of the stash entry and not the stash entry itself, running `git stash show` does not include the untracked files as part of the diff. With --include-untracked, untracked paths, which are recorded in the third-parent if it exists, are shown in addition to the paths that have modifications between the stash base and the working tree in the stash. It is possible to manually craft a malformed stash entry where duplicate untracked files in the stash entry will mask tracked files. We detect and error out in that case via a custom unpack_trees() callback: stash_worktree_untracked_merge(). Also, teach stash the --only-untracked option which only shows the untracked files of a stash entry. This is similar to `git show stash^3` but it is nice to provide a convenient abstraction for it so that users do not have to think about the underlying implementation. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-12Merge branch 'jk/complete-branch-force-delete'Libravatar Junio C Hamano1-2/+4
The command line completion (in contrib/) completed "git branch -d" with branch names, but "git branch -D" offered tagnames in addition, which has been corrected. "git branch -M" had the same problem. * jk/complete-branch-force-delete: doc/git-branch: fix awkward wording for "-c" completion: handle other variants of "branch -m" completion: treat "branch -D" the same way as "branch -d"
2021-02-03completion: handle other variants of "branch -m"Libravatar Jeff King1-2/+4
We didn't special-case "branch -M" (with a capital M) the same as "branch -m", nor any of the "--copy" variants. As a result these offered any ref as the next candidate, and not just branch names. Note that I rewrapped case-arm line since it's now quite long, and likewise the one below it for consistency. I also re-ordered the existing "-D" to make it more obvious how the cases group together. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-02completion: treat "branch -D" the same way as "branch -d"Libravatar Jeff King1-1/+1
The former offers not just branches but tags as completion candidates. Mimic how "branch -d" limits its suggestion to branch names. Reported-by: Paul Jolly <paul@myitcv.io> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04completion: add proper public __git_completeLibravatar Felipe Contreras1-7/+33
When __git_complete was introduced, it was meant to be temporarily, while a proper guideline for public shell functions was established (tentatively _GIT_complete), but since that never happened, people in the wild started to use __git_complete, even though it was marked as not public. Eight years is more than enough wait, let's mark this function as public, and make it a bit more user-friendly. So that instead of doing: __git_complete gk __gitk_main The user can do: __git_complete gk gitk And instead of: __git_complete gf _git_fetch Do: __git_complete gf git_fetch Backwards compatibility is maintained. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04completion: bash: improve function detectionLibravatar Felipe Contreras1-1/+1
1. We should quote the argument 2. We don't need two redirections 3. A safeguard for arguments (-a) would be good Suggested-by: René Scharfe <l.s.r@web.de> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04completion: bash: add __git_have_func helperLibravatar Felipe Contreras1-3/+7
This makes the code more readable, and also will help when new code wants to do similar checks. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-08Merge branch 'fc/zsh-completion'Libravatar Junio C Hamano1-1/+1
Hotfix for a recent breakage. * fc/zsh-completion: completion: bash: fix gitk alias regression completion: zsh: fix file completion regression
2020-12-07completion: bash: fix gitk alias regressionLibravatar Felipe Contreras1-1/+1
Long time ago when the _git_complete helper was introduced, _gitk was replaced with __gitk_main, and a placeholder for backwards compatibility pointing to __git_wrap_main_gitk was left in place. When "__git_complete gitk __gitk_main" was called, that created the __git_wrap__gitk_main helper, which is just basically "__git_func_wrap __gitk_main" plus `complete` options. Unfortunately the commit b0a4b2d257 (completion: add support for backwards compatibility, 2012-05-19) missed a previous instance of a call to _gitk in _git_gitk So, basically we had __git_wrap__git_main -> __git_func_wrap __git_main -> __git_complete_command gitk -> _git_gitk -> _gitk -> __git_wrap__gitk_main -> __git_func_wrap __gitk_main -> __gitk_main. There was never any need to call __git_func_wrap twice. Since _git_gitk is always called inside the wrapper, it can call __gitk_main directly. And then, in commit 441ecdab37 (completion: bash: remove old compat wrappers, 2020-10-27) _gitk was removed, which triggers the following error: _git_gitk:9: command not found: _gitk Let's call the correct function: __gitk_main. Cc: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-17completion: bash: improve alias loop detectionLibravatar Felipe Contreras1-4/+5
It is possible for the name of an alias to end with the name of another alias, in which case the code will incorrectly detect a loop. We can fix that by adding an extra space between words. Suggested-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-09completion: bash: check for alias loopLibravatar Felipe Contreras1-3/+8
We don't want to be stuck in an endless cycle. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-09completion: bash: support recursive aliasesLibravatar Felipe Contreras1-19/+31
It is possible to have recursive aliases like: l = log --oneline lg = l --graph So the completion should detect such aliases as well. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-09Merge branch 'fc/zsh-completion'Libravatar Junio C Hamano1-103/+10
Zsh autocompletion (in contrib/) update. * fc/zsh-completion: (29 commits) zsh: update copyright notices completion: bash: remove old compat wrappers completion: bash: cleanup cygwin check completion: bash: trivial cleanup completion: zsh: add simple version check completion: zsh: trivial simplification completion: zsh: add alias descriptions completion: zsh: improve command tags completion: zsh: refactor command completion completion: zsh: shuffle functions around completion: zsh: simplify file_direct completion: zsh: simplify nl_append completion: zsh: trivial cleanup completion: zsh: simplify direct compadd completion: zsh: simplify compadd functions completion: zsh: fix splitting of words completion: zsh: add missing direct_append completion: fix conflict with bashcomp completion: zsh: fix completion for --no-.. options completion: bash: remove zsh wrapper ...
2020-11-02Merge branch 'dl/diff-merge-base'Libravatar Junio C Hamano1-9/+6
"git diff A...B" learned "git diff --merge-base A B", which is a longer short-hand to say the same thing. * dl/diff-merge-base: contrib/completion: complete `git diff --merge-base` builtin/diff-tree: learn --merge-base builtin/diff-index: learn --merge-base t4068: add --merge-base tests diff-lib: define diff_get_merge_base() diff-lib: accept option flags in run_diff_index() contrib/completion: extract common diff/difftool options git-diff.txt: backtick quote command text git-diff-index.txt: make --cached description a proper sentence t4068: remove unnecessary >tmp