summaryrefslogtreecommitdiff
path: root/contrib/completion
AgeCommit message (Collapse)AuthorFilesLines
2021-12-15Merge branch 'en/zdiff3'Libravatar Junio C Hamano1-3/+3
"Zealous diff3" style of merge conflict presentation has been added. * en/zdiff3: update documentation for new zdiff3 conflictStyle xdiff: implement a zealous diff3, or "zdiff3"
2021-12-10Merge branch 'yn/complete-date-format-options'Libravatar Junio C Hamano1-1/+1
The completion script (in contrib/) learns that the "--date" option of commands from the "git log" family takes "human" and "auto" as valid values. * yn/complete-date-format-options: completion: add human and auto: date format
2021-12-01xdiff: implement a zealous diff3, or "zdiff3"Libravatar Phillip Wood1-3/+3
"zdiff3" is identical to ordinary diff3 except that it allows compaction of common lines on the two sides of history at the beginning or end of the conflict hunk. For example, the following diff3 conflict: 1 2 3 4 <<<<<< A B C D E |||||| 5 6 ====== A X C Y E >>>>>> 7 8 9 has common lines 'A', 'C', and 'E' on the two sides. With zdiff3, one would instead get the following conflict: 1 2 3 4 A <<<<<< B C D |||||| 5 6 ====== X C Y >>>>>> E 7 8 9 Note that the common lines, 'A', and 'E' were moved outside the conflict. Unlike with the two-way conflicts from the 'merge' conflictStyle, the zdiff3 conflict is NOT split into multiple conflict regions to allow the common 'C' lines to be shown outside a conflict, because zdiff3 shows the base version too and the base version cannot be reasonably split. Note also that the removing of lines common to the two sides might make the remaining text inside the conflict region match the base text inside the conflict region (for example, if the diff3 conflict had '5 6 E' on the right side of the conflict, then the common line 'E' would be moved outside and both the base and right side's remaining conflict text would be the lines '5' and '6'). This has the potential to surprise users and make them think there should not have been a conflict, but there definitely was a conflict and it should remain. Based-on-patch-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Co-authored-by: Elijah Newren <newren@gmail.com> Signed-off-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-29Merge branch 'tp/send-email-completion'Libravatar Junio C Hamano1-10/+1
The command line complation for "git send-email" options have been tweaked to make it easier to keep it in sync with the command itself. * tp/send-email-completion: send-email docs: add format-patch options send-email: programmatically generate bash completions
2021-11-25completion: add human and auto: date formatLibravatar Yoichi Nakayama1-1/+1
human was introduced in acdd37769de8b0fe37a74bfc0475b63bdc55e9dc auto:* was introduced in 2fd7c22992d37469db957e9a4d3884a6c0a4d182 Those formats were missing when other values were added to completion at 5a59a2301f6ec9bcf1b101edb9ca33beb465842f Signed-off-by: Yoichi Nakayama <yoichi.nakayama@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-28send-email: programmatically generate bash completionsLibravatar Thiago Perrotta1-10/+1
"git send-email --git-completion-helper" only prints "format-patch" flags. Make it print "send-email" flags as well, extracting them programmatically from its three existing "GetOptions". Introduce a "uniq" subroutine, otherwise --cc-cover, --to-cover and other flags would show up twice. In addition, deduplicate flags common to both "send-email" and "format-patch", like --from. Remove extraneous flags: --h and --git-completion-helper. Add trailing "=" to options that expect an argument, inline with the format-patch implementation. Add a completion test for "send-email --validate", a send-email flag. Signed-off-by: Thiago Perrotta <tbperrotta@gmail.com> Based-on-patch-by: Ævar Arnfjörð Bjarmason <avarab@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 'ti/tcsh-completion-regression-fix' into maintLibravatar Junio C Hamano1-2/+3
Update to the command line completion (in contrib/) for tcsh. * ti/tcsh-completion-regression-fix: completion: tcsh: Fix regression by drop of wrapper functions
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 'ti/tcsh-completion-regression-fix'Libravatar Junio C Hamano1-2/+3
Update to the command line completion (in contrib/) for tcsh. * ti/tcsh-completion-regression-fix: completion: tcsh: Fix regression by drop of wrapper functions
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: tcsh: Fix regression by drop of wrapper functionsLibravatar Takashi Iwai1-2/+3
The cleanup of old compat wrappers in bash completion caused a regression on tcsh completion that still uses them. Let's update the tcsh call site as well for addressing it. Fixes: 441ecdab37fe ("completion: bash: remove old compat wrappers") Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 Aguilar2-2/+2
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-20Merge branch 'en/prompt-under-set-u'Libravatar Junio C Hamano1-3/+3
The bash prompt script (in contrib/) did not work under "set -u". * en/prompt-under-set-u: git-prompt: work under set -u
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-13git-prompt: work under set -uLibravatar Elijah Newren1-3/+3
Commit afda36dbf3 ("git-prompt: include sparsity state as well", 2020-06-21) added the use of some variables to control how to show sparsity state in the git prompt, but implicitly assumed that undefined variables would be treated as the empty string. This breaks users who run under 'set -u'; fix the code to be more explicit. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>