summaryrefslogtreecommitdiff
path: root/contrib/completion
AgeCommit message (Collapse)Author
2020-09-26completion: complete refs after 'git restore -s'Ákos Uzonyi
Currently only the long version (--source=) supports completion. Add completion support to the short (-s) option too. Signed-off-by: Ákos Uzonyi <uzonyi.akos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-26completion: use "prev" variable instead of introducing "prevword"Ákos Uzonyi
In both _git_checkout and _git_switch a new "prevword" variable were introduced, however the "prev" variable already contains the last word. The "prevword" variable is replaced with "prev", and the case is moved to the beginning of the function, like it's done in many other places (e.g. _git_commit). Also the indentaion of the case is fixed. Signed-off-by: Ákos Uzonyi <uzonyi.akos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17contrib/completion: complete options that take refs for format-patchDenton Liu
The completion for format-patch currently suggests --base=, --interdiff= and --range-diff= as options. However, with these `=` forms of the options, there is no space and we'd enter the `--*` case which means we don't call the __git_complete_revlist() at the end. Teach _git_format_patch() to complete refs in the case of --base=, --interdiff= and --range-diff=. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-20completion: add GIT_COMPLETION_SHOW_ALL env varRyan Zoeller
When set to 1, GIT_COMPLETION_SHOW_ALL causes --git-completion-helper-all to be passed instead of --git-completion-helper. Signed-off-by: Ryan Zoeller <rtzoeller@rtzoeller.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-18Merge branch 'pd/mergetool-nvimdiff'Junio C Hamano
The existing backends for "git mergetool" based on variants of vim have been refactored and then support for "nvim" has been added. * pd/mergetool-nvimdiff: mergetools: add support for nvimdiff (neovim) family mergetool--lib: improve support for vimdiff-style tool variants
2020-08-04Merge branch 'mp/complete-show-color-moved'Junio C Hamano
Command line completion (in contrib/) update. * mp/complete-show-color-moved: completion: add show --color-moved[-ws]
2020-07-29mergetools: add support for nvimdiff (neovim) familypudinha
Signed-off-by: pudinha <rogi@skylittlesystem.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-21Merge branch 'en/sparse-status' into masterJunio C Hamano
Fix to a "git prompt" regression during this development cycle. * en/sparse-status: git-prompt: change == to = for zsh's sake
2020-07-21git-prompt: change == to = for zsh's sakeDavid J. Malan
When using git-prompt.sh with zsh, __git_ps1 currently errs when inside a repo with: __git_ps1:96: = not found Avoid using non-portable "==" that is only understood by bash and not zsh. Change to "=" so that the prompt script becomes usable with zsh again. Signed-off-by: David J. Malan <malan@harvard.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-15completion: add show --color-moved[-ws]Michal Privoznik
The completion for diff command was added in fd0bc175576 but missed the show command which also supports --color-moved[-ws]. This suffers from the very same problem [1] as the referenced commit: no comma-separated list completion for --color-moved-ws. [1]: https://github.com/scop/bash-completion/issues/240 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-09Merge branch 'vs/completion-with-set-u' into masterJunio C Hamano
The command line completion support (in contrib/) used to be prepared to work with "set -u" but recent changes got a bit more sloppy. This has been corrected. * vs/completion-with-set-u: completion: nounset mode fixes
2020-07-07Merge branch 'en/sparse-status'Junio C Hamano
"git status" learned to report the status of sparse checkout. * en/sparse-status: git-prompt: include sparsity state as well git-prompt: document how in-progress operations affect the prompt wt-status: show sparse checkout status as well
2020-07-01completion: nounset mode fixesVille Skyttä
Accessing unset variables results an errors when the shell is in nounset/-u mode. This fixes the cases I've come across while using git completion in a shell running in that mode for a while. It's hard to tell if this is the complete set, but at least it improves things. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-25Merge branch 'jk/complete-git-switch'Junio C Hamano
The command line completion (in contrib/) learned to complete options that the "git switch" command takes. * jk/complete-git-switch: completion: improve handling of --orphan option of switch/checkout completion: improve handling of -c/-C and -b/-B in switch/checkout completion: improve handling of --track in switch/checkout completion: improve handling of --detach in checkout completion: improve completion for git switch with no options completion: improve handling of DWIM mode for switch/checkout completion: perform DWIM logic directly in __git_complete_refs completion: extract function __git_dwim_remote_heads completion: replace overloaded track term for __git_complete_refs completion: add tests showing subpar switch/checkout --orphan logic completion: add tests showing subpar -c/C argument completion completion: add tests showing subpar -c/-C startpoint completion completion: add tests showing subpar switch/checkout --track logic completion: add tests showing subar checkout --detach logic completion: add tests showing subpar DWIM logic for switch/checkout completion: add test showing subpar git switch completion
2020-06-22git-prompt: include sparsity state as wellElijah Newren
git-prompt includes the current branch, a bunch of single character mini-state displayers, and some much longer in-progress state notifications. The current branch is always shown. The single character mini-state displayers are all off by default (they are not self explanatory) but each has an environment variable for turning it on. The in-progress state notifications provide no configuration options for turning them off, and can be up to 15 characters long (e.g. "|REBASE (12/18)" or "|CHERRY-PICKING"). The single character mini-state tends to be used for things like "Do you have any stashes in refs/stash?" or "Are you ahead or behind of upstream?". These are things which users can take advantage of but do not affect most normal git operations. The in-progress states, by contrast, suggest the user needs to interact differently and may also prevent some normal operations from succeeding (e.g. git switch may show an error instead of switching branches). Sparsity is like the in-progress states in that it suggests a fundamental different interaction with the repository (many of the files from the repository are not present in your working copy!). A few commits ago added sparsity information to wt_longstatus_print_state(), grouping it with other in-progress state displays. We do similarly here with the prompt and show the extra state, by default, with an extra |SPARSE This state can be present simultaneously with the in-progress states, in which case it will appear before the other states; for example, (branchname|SPARSE|REBASE 6/10) The reason for showing the "|SPARSE" substring before other states is to emphasize those other states. Sparsity is probably not going to change much within a repository, while temporary operations will. So we want the state changes related to temporary operations to be listed last, to make them appear closer to where the user types and make them more likely to be noticed. The fact that sparsity isn't just cached metadata or additional information is what leads us to show it more similarly to the in-progress states, but the fact that sparsity is not transient like the in-progress states might cause some users to want an abbreviated notification of sparsity state or perhaps even be able to turn it off. Allow GIT_PS1_COMPRESSSPARSESTATE to be set to request that it be shortened to a single character ('?'), and GIT_PS1_OMITSPARSESTATE to be set to request that sparsity state be omitted from the prompt entirely. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22git-prompt: document how in-progress operations affect the promptElijah Newren
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-09Merge branch 'vs/complete-stash-show-p-fix'Junio C Hamano
The command line completion script (in contrib/) tried to complete "git stash -p" as if it were "git stash push -p", but it was too aggressive and also affected "git stash show -p", which has been corrected. * vs/complete-stash-show-p-fix: completion: don't override given stash subcommand with -p
2020-05-28completion: improve handling of --orphan option of switch/checkoutJacob Keller
The --orphan option is used to create a local branch which is detached from the current history. In git switch, it always resets to the empty tree, and thus the only completion we can provide is a branch name. Follow the same rules for -c/-C (and -b/-B) when completing the argument to --orphan. In the case of git switch, after we complete the argument, there is nothing more we can complete for git switch, so do not even try. Nothing else would be valid. In the case of git checkout, --orphan takes a start point which it uses to determine the checked out tree, even though it created orphaned history. Update the previously added test cases as they are now passing. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve handling of -c/-C and -b/-B in switch/checkoutJacob Keller
A previous commit added several test cases highlighting the subpar completion logic for -c/-C and -b/-B when completing git switch and git checkout. In order to distinguish completing the argument vs the start-point for this option, we now use the wordlist to determine the previous full word on the command line. If it's -c or -C (-b/-B for checkout), then we know that we are completing the argument for the branch name. Given that a user who already knows the branch name they want to complete will simply not use completion, it makes sense to complete the small subset of local branches when completing the argument for -c/-C. In all other cases, if -c/-C are on the command line but are not the most recent option, then we must be completing a start-point, and should allow completing against all references. Update the -c/-C and -b/-B tests to indicate they now pass. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve handling of --track in switch/checkoutJacob Keller
Current completion for the --track option of git switch and git checkout is sub par. In addition to the DWIM logic of a bare branch name, --track has DWIM logic to convert specified remote/branch names into a local branch tracking that remote. For example $git switch --track origin/master This will create a local branch name master, that tracks the master branch of the origin remote. In fact, git switch --track on its own will not accept other forms of references. These must instead be specified manually via the -c/-C/-b/-B options. Introduce __git_remote_heads() and the "remote-heads" mode for __git_complete_refs. Use this when the --track option is provided while completing in _git_switch and _git_checkout. Just as in the --detach case, we never enable DWIM mode for --track, because it doesn't make sense. It should be noted that completion support is still a bit sub par when it comes to handling -c/-C and --orphan. This will be resolved in a future change. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve handling of --detach in checkoutJacob Keller
Just like git switch, we should not complete DWIM remote branch names if --detach has been specified. To avoid this, refactor _git_checkout in a similar way to _git_switch. Note that we don't simply clear dwim_opt when we find -d or --detach, as we will be adding other modes and checks, making this flow easier to follow. Update the previously failing tests to show that the breakage has been resolved. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve completion for git switch with no optionsJacob Keller
Add a new --mode option to __git_complete_refs, which allows changing the behavior to call __git_heads instead of __git_refs. By passing --mode=heads, __git_complete_refs will only output local branches. This enables using "--mode=heads --dwim" to enable listing local branches and the remote unique branch names for DWIM. Refactor completion support to use the new mode option, rather than calling __git_heads directly. This has the advantage that we can now correctly allow local branches along with suitable DWIM refs, rather than only allowing DWIM when we complete all references. Choose what mode it uses when calling __git_complete_refs. If -d or --detach have been provided, then simply complete all refs, but *without* the DWIM option as these DWIM names won't work properly in --detach mode. Otherwise, call __git_complete_refs with the default dwim_opt value and use the new "heads" mode. In this way, the basic support for completing just "git switch <TAB>" will result in only local branches and remote unique names for DWIM. The basic no-options tests for git switch, as well as several of the -c/-C tests now pass, so remove the known breakage tags. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: improve handling of DWIM mode for switch/checkoutJacob Keller
A new helper, __git_find_last_on_cmdline is introduced, similar to the already existing __git_find_on_cmdline, but which operates in reverse, finding the *last* matching word of the provided wordlist. Use this in a new __git_checkout_default_dwim_mode() function that will determine when to enable listing of DWIM remote branches. The __git_find_last_on_cmdline() function is used to determine which --guess or --no-guess is in effect. If either one is provided, then we unconditionally enable or disable the DWIM mode based on the last provided option. If neither --guess nor --no-guess is provided, then we check for --no-track, and finally for GIT_COMPLETION_CHECKOUT_NO_GUESS=1. This function is then used in _git_switch and _git_checkout to improve the handling for when we enable listing of these DWIM remote branches. This new logic is more robust, as we will correctly identify superseded options, and ensure that both _git_switch and _git_checkout enable DWIM in similar ways. We can now update a few tests to indicate they pass. A few of the tests previously added to highlight issues with the old DWIM logic still fail. This is because of a separate issue related to the default completion behavior of git switch, which will be addressed in a future change. Additionally, due to this change, a few tests for the -b/-B handling of git checkout now fail. This is a minor regression, and will be fixed by a following change that improves the overall handling of -b/-B. Mark these tests as known breakages for now. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: perform DWIM logic directly in __git_complete_refsJacob Keller
__git_complete_refs is the main function used for completing references. It is primarily used as a wrapper around __git_refs, and is easier to extend since its arguments are option-like. One major downside of __git_complete_refs and __git_refs currently, is the lack of ability to complete only a subset of refs such as branches (refs/heads) or tags (refs/tags). Normally, a caller might just decide to use __git_heads() or __git_tags(). However, in the case of git-switch, it is useful to complete both branches *and* DWIM remote branch names. Due to the complexity and implementation of __git_refs, it is not easy to extend it to support listing only a subset of references. Instead, we can extend __git_complete_refs to do this. For this to be done, we must first ensure that "--dwim" support is not tied to calling __git_refs. Instead of passing $dwim into __git_refs, we can implement a __gitcomp_direct_append function which can append to COMPREPLY after a call to __gitcomp_direct. If --dwim is passed to __git_complete_refs, use __gitcomp_direct_append to add the output of __git_dwim_remote_heads to the completion list. In this way, --dwim support is now independent of calling __git_refs. A future change will add an additional option to control what set of references __git_complete_refs will output. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: extract function __git_dwim_remote_headsJacob Keller
__git_refs() has the ability to report unique remote names for supporting completion of remote branch names for the DWIMery of git checkout and git switch. For git checkout, this is fine, because it always supports completing all local references. However, git switch by default only supports either switching branches or using this DWIMery to create a local branch tracking the remote branch. Future work to cleanup and improve completion support for git switch will be aided if the remote branch names can be completed separately from __git_refs. Extract this logic to a function __git_dwim_remote_heads(), and use it in __git_refs. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: replace overloaded track term for __git_complete_refsJacob Keller
The __git_complete_refs uses the "--track" option to specify when to enable listing of unique remote branches which are used by the DWIM logic of git checkout and git switch. Using the term '--track' here is confusing because the git commands themselves have '--track' as an argument. Additionally, the completion logic for _git_switch also checks for --track. Keeping the meaning of track_opt and --track for __git_complete_refs straight from the --track git switch and git checkout option is difficult when reading this code. Use the option '--dwim' instead, indicating this is about enabling or disabling logic related to DWIM mode. Also rename the local variable track_opt to dwim_opt to further reduce the confusion when reading the completion code for _git_switch. Because it is plausible for users to have developed their own completions which rely on __git_complete_ref, keep --track as a synonym for --dwim, even though we no longer use it in any of the core git completion logic. Add a comment explaining why it remains as an alternative spelling for --dwim. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-28completion: use native ZSH array pattern matchingMarco Trevisan (Treviño)
When clearing the builtin operations on re-sourcing in the ZSH case we can use the native ${parameters} associative array keys values to get the currently `__gitcomp_builtin_*` operations using pattern matching instead of using sed. As also stated in commit 94408dc7, introducing this change the usage of sed has some overhead implications, while ZSH can do this check just using its native syntax. Signed-off-by: Marco Trevisan (Treviño) <mail@3v1n0.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-21completion: don't override given stash subcommand with -pVille Skyttä
df70b190 (completion: make stash -p and alias for stash push -p, 2018-04-20) wanted to make sure "git stash -p <TAB>" offers the same completion as "git stash push -p <TAB>", but it did so by forcing the $subcommand to be "push" whenever then "-p" option is found on the command line. This harms any subcommand that can take the "-p" option---even when the subcommand is explicitly given, e.g. "git stash show -p", the code added by the change would overwrite the $subcommand the user gave us. Fix it by making sure that the defaulting to "push" happens only when there is no $subcommand given yet. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-14Merge branch 'ds/bloom-cleanup'Junio C Hamano
Code cleanup and typofixes * ds/bloom-cleanup: completion: offer '--(no-)patch' among 'git log' options bloom: use num_changes not nr for limit detection bloom: de-duplicate directory entries Documentation: changed-path Bloom filters use byte words bloom: parse commit before computing filters test-bloom: fix usage typo bloom: fix whitespace around tab length
2020-05-11completion: offer '--(no-)patch' among 'git log' optionsSZEDER Gábor
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-29Merge branch 'en/fill-directory-exponential'Junio C Hamano
The directory traversal code had redundant recursive calls which made its performance characteristics exponential with respect to the depth of the tree, which was corrected. * en/fill-directory-exponential: completion: fix 'git add' on paths under an untracked directory Fix error-prone fill_directory() API; make it only return matches dir: replace double pathspec matching with single in treat_directory() dir: include DIR_KEEP_UNTRACKED_CONTENTS handling in treat_directory() dir: replace exponential algorithm with a linear one dir: refactor treat_directory to clarify control flow dir: fix confusion based on variable tense dir: fix broken comment dir: consolidate treat_path() and treat_one_path() dir: fix simple typo in comment t3000: add more testcases testing a variety of ls-files issues t7063: more thorough status checking
2020-04-17complete: zsh: add missing sub cmd completion candidatesTerry Moschou
Add missing 'restore' and 'switch' sub commands to zsh completion candidate output. E.g. $ git re<tab> rebase -- forward-port local commits to the updated upstream head reset -- reset current HEAD to the specified state restore -- restore working tree files $ git s<tab> show -- show various types of objects status -- show the working tree status switch -- switch branches Signed-off-by: Terry Moschou <tmoschou@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-01completion: fix 'git add' on paths under an untracked directoryElijah Newren
As reported on the git mailing list, since git-2.25, git add untracked-dir/ has been tab completing to git add untracked-dir/./ The cause for this was that with commit b9670c1f5e (dir: fix checks on common prefix directory, 2019-12-19), git ls-files -o --directory untracked-dir/ (or the equivalent `git -C untracked-dir ls-files -o --directory`) began reporting untracked-dir/ instead of listing paths underneath that directory. It may also be worth noting that the real command in question was git -C untracked-dir ls-files -o --directory '*' which is equivalent to git ls-files -o --directory 'untracked-dir/*' which behaves the same for the purposes of this issue (the '*' can match the empty string), but becomes relevant for the proposed fix. At first, based on the report, I decided to try to view this as a regression and tried to find a way to recover the old behavior without breaking other stuff, or at least breaking as little as possible. However, in the end, I couldn't figure out a way to do it that wouldn't just cause lots more problems than it solved. The old behavior was a bug: * Although older git would avoid cleaning anything with `git clean -f .git`, it would wipe out everything under that direcotry with `git clean -f .git/`. Despite the difference in command used, this is relevant because the exact same change that fixed clean changed the behavior of ls-files. * Older git would report different results based solely on presence or absence of a trailing slash for $SUBDIR in the command `git ls-files -o --directory $SUBDIR`. * Older git violated the documented behavior of not recursing into directories that matched the pathspec when --directory was specified. * And, after all, commit b9670c1f5e (dir: fix checks on common prefix directory, 2019-12-19) didn't overlook this issue; it explicitly stated that the behavior of the command was being changed to bring it inline with the docs. (Also, if it helps, despite that commit being merged during the 2.25 series, this bug was not reported during the 2.25 cycle, nor even during most of the 2.26 cycle -- it was reported a day before 2.26 was released. So the impact of the change is at least somewhat small.) Instead of relying on a bug of ls-files in reporting the wrong content, change the invocation of ls-files used by git-completion to make it grab paths one depth deeper. Do this by changing '$DIR/*' (match $DIR/ plus 0 or more characters) into '$DIR/?*' (match $DIR/ plus 1 or more characters). Note that the '?' character should not be added when trying to complete a filename (e.g. 'git ls-files -o --directory "merge.c?*"' would not correctly return "merge.c" when such a file exists), so we have to make sure to add the '?' character only in cases where the path specified so far is a directory. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-09Merge branch 'kk/complete-diff-color-moved'Junio C Hamano
Completion update. * kk/complete-diff-color-moved: completion: add diff --color-moved[-ws]
2020-03-09Merge branch 'pb/am-show-current-patch'Junio C Hamano
"git am --short-current-patch" is a way to show the piece of e-mail for the stopped step, which is not suitable to directly feed "git apply" (it is designed to be a good "git am" input). It learned a new option to show only the patch part. * pb/am-show-current-patch: am: support --show-current-patch=diff to retrieve .git/rebase-apply/patch am: support --show-current-patch=raw as a synonym for--show-current-patch am: convert "resume" variable to a struct parse-options: convert "command mode" to a flag parse-options: add testcases for OPT_CMDMODE()
2020-03-02Merge branch 'en/rebase-backend'Junio C Hamano
"git rebase" has learned to use the merge backend (i.e. the machinery that drives "rebase -i") by default, while allowing "--apply" option to use the "apply" backend (e.g. the moral equivalent of "format-patch piped to am"). The rebase.backend configuration variable can be set to customize. * en/rebase-backend: rebase: rename the two primary rebase backends rebase: change the default backend from "am" to "merge" rebase: make the backend configurable via config setting rebase tests: repeat some tests using the merge backend instead of am rebase tests: mark tests specific to the am-backend with --am rebase: drop '-i' from the reflog for interactive-based rebases git-prompt: change the prompt for interactive-based rebases rebase: add an --am option rebase: move incompatibility checks between backend options a bit earlier git-rebase.txt: add more details about behavioral differences of backends rebase: allow more types of rebases to fast-forward t3432: make these tests work with either am or merge backends rebase: fix handling of restrict_revision rebase: make sure to pass along the quiet flag to the sequencer rebase, sequencer: remove the broken GIT_QUIET handling t3406: simplify an already simple test rebase (interactive-backend): fix handling of commits that become empty rebase (interactive-backend): make --keep-empty the default t3404: directly test the behavior of interest git-rebase.txt: update description of --allow-empty-message
2020-02-24completion: add diff --color-moved[-ws]Kir Kolyshkin
These options are available since git v2.15, but somehow eluded from the completion script. Note that while --color-moved-ws= accepts comma-separated list of values, there is no (easy?) way to make it work with completion (see e.g. [1]). [1]: https://github.com/scop/bash-completion/issues/240 Acked-by: Matheus Tavares Bernardino <matheus.bernardino@usp.br> Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-20am: support --show-current-patch=diff to retrieve .git/rebase-apply/patchPaolo Bonzini
When "git am --show-current-patch" was added in commit 984913a210 ("am: add --show-current-patch", 2018-02-12), "git am" started recommending it as a replacement for .git/rebase-merge/patch. Unfortunately the suggestion is somewhat misguided; for example, the output of "git am --show-current-patch" cannot be passed to "git apply" if it is encoded as quoted-printable or base64. Add a new mode to "git am --show-current-patch" in order to straighten the suggestion. Reported-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-20am: support --show-current-patch=raw as a synonym for--show-current-patchPaolo Bonzini
When "git am --show-current-patch" was added in commit 984913a210 ("am: add --show-current-patch", 2018-02-12), "git am" started recommending it as a replacement for .git/rebase-merge/patch. Unfortunately the suggestion is somewhat misguided; for example, the output "git am --show-current-patch" cannot be passed to "git apply" if it is encoded as quoted-printable or base64. To simplify worktree operations and to avoid that users poke into .git, it would be better if "git am" also provided a mode that copies .git/rebase-merge/patch to stdout. One possibility could be to have completely separate options, introducing for example --show-current-message (for .git/rebase-apply/NNNN) and --show-current-diff (for .git/rebase-apply/patch), while possibly deprecating --show-current-patch. That would even remove the need for the first two patches in the series. However, the long common prefix would have prevented using an abbreviated option such as "--show". Therefore, I chose instead to add a string argument to --show-current-patch. The new argument is optional, so that "git am --show-current-patch"'s behavior remains backwards-compatible. The next choice to make is how to handle multiple --show-current-patch options. Right now, something like "git am --abort --show-current-patch" is rejected, and the previous suggestion would likewise have naturally rejected a command line like git am --show-current-message --show-current-diff Therefore, I decided to also reject for example git am --show-current-patch=diff --show-current-patch=raw In other words the whole of --show-current-patch=xxx (including the optional argument) is treated as the command mode. I found this to be more consistent and intuitive, even though it differs from the usual "last one wins" semantics of the git command line. Add the code to parse submodes based on the above design, where for now "raw" is the only valid submode. "raw" prints the full e-mail message just like "git am --show-current-patch". Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16git-prompt: change the prompt for interactive-based rebasesElijah Newren
In the past, we had different prompts for different types of rebases: REBASE: for am-based rebases REBASE-m: for merge-based rebases REBASE-i: for interactive-based rebases It's not clear why this distinction was necessary or helpful; when the prompt was added in commit e75201963f67 ("Improve bash prompt to detect various states like an unfinished merge", 2007-09-30), it simply added these three different types. Perhaps there was a useful purpose back then, but there have been some changes: * The merge backend was deleted after being implemented on top of the interactive backend, causing the prompt for merge-based rebases to change from REBASE-m to REBASE-i. * The interactive backend is used for multiple different types of non-interactive rebases, so the "-i" part of the prompt doesn't really mean what it used to. * Rebase backends have gained more abilities and have a great deal of overlap, sometimes making it hard to distinguish them. * Behavioral differences between the backends have also been ironed out. * We want to change the default backend from am to interactive, which means people would get "REBASE-i" by default if we didn't change the prompt, and only if they specified --am or --whitespace or -C would they get the "REBASE" prompt. * In the future, we plan to have "--whitespace", "-C", and even "--am" run the interactive backend once it can handle everything the am-backend can. For all these reasons, make the prompt for any type of rebase just be "REBASE". Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-05Merge branch 'mt/sparse-checkout-doc-update'Junio C Hamano
Doc update. * mt/sparse-checkout-doc-update: completion: add support for sparse-checkout doc: sparse-checkout: mention --cone option
2020-01-30Merge branch 'sg/completion-worktree'Junio C Hamano
The command line completion (in contrib/) learned to complete subcommands and arguments to "git worktree". * sg/completion-worktree: completion: list paths and refs for 'git worktree add' completion: list existing working trees for 'git worktree' subcommands completion: simplify completing 'git worktree' subcommands and options completion: return the index of found word from __git_find_on_cmdline() completion: clean up the __git_find_on_cmdline() helper function t9902-completion: add tests for the __git_find_on_cmdline() helper
2020-01-23completion: add support for sparse-checkoutMatheus Tavares
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15completion: list paths and refs for 'git worktree add'SZEDER Gábor
Complete paths after 'git worktree add <TAB>' and refs after 'git worktree add -b <TAB>' and 'git worktree add some/dir <TAB>'. Uncharacteristically for a Git command, 'git worktree add' takes a mandatory path parameter before a commit-ish as its optional last parameter. In addition, it has both standalone --options and options with a mandatory unstuck parameter ('-b <new-branch>'). Consequently, trying to complete refs for that last optional commit-ish parameter resulted in a more convoluted than usual completion function, but hopefully all the included comments will make it not too hard to digest. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15completion: list existing working trees for 'git worktree' subcommandsSZEDER Gábor
Complete the paths of existing working trees for 'git worktree's 'move', 'remove', 'lock', and 'unlock' subcommands. Note that 'git worktree list --porcelain' shows absolute paths, so for simplicity's sake we'll complete full absolute paths as well (as opposed to turning them into relative paths by finding common leading directories between $PWD and the working tree's path and removing them, risking trouble with symbolic links or Windows drive letters; or completing them one path component at a time). Never list the path of the main working tree, as it cannot be moved, removed, locked, or unlocked. Ideally we would only list unlocked working trees for the 'move', 'remove', and 'lock' subcommands, and only locked ones for 'unlock'. Alas, 'git worktree list --porcelain' doesn't indicate which working trees are locked, so for now we'll complete the paths of all existing working trees. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15completion: simplify completing 'git worktree' subcommands and optionsSZEDER Gábor
The completion function for 'git worktree' uses separate but very similar case arms to complete --options for each subcommand. Combine these into a single case arm to avoid repetition. Note that after this change we won't complete 'git worktree remove's '--force' option, but that is consistent with our general stance on not offering '--force', as it should be used with care. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15completion: return the index of found word from __git_find_on_cmdline()SZEDER Gábor
When using the __git_find_on_cmdline() helper function so far we've only been interested in which one of a set of words appear on the command line. To complete options for some of 'git worktree's subcommands in the following patches we'll need not only that, but the index of that word on the command line as well. Extend __git_find_on_cmdline() to optionally show the index of the found word on the command line (IOW in the $words array) when the '--show-idx' option is given. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15completion: clean up the __git_find_on_cmdline() helper functionSZEDER Gábor
The __git_find_on_cmdline() helper function started its life as __git_find_subcommand() [1], but it served a more general purpose than looking for subcommands, so later it was renamed accordingly [2]. However, that rename didn't touch the body of the function, and left the $subcommand local variable behind, still reminiscent of the function's original purpose. Let's clean up the names of __git_find_on_cmdline()'s local variables and get rid of that $subcommand variable name. While at it, add a short comment describing the function's purpose. [1] 3ff1320d4b (bash: refactor searching for subcommands on the command line, 2008-03-10), [2] 918c03c2a7 (bash: rename __git_find_subcommand() to __git_find_on_cmdline(), 2009-09-15) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-10Merge branch 'dl/pretty-reference'Junio C Hamano
"git log" family learned "--pretty=reference" that gives the name of a commit in the format that is often used to refer to it in log messages. * dl/pretty-reference: SubmittingPatches: use `--pretty=reference` pretty: implement 'reference' format pretty: add struct cmt_fmt_map::default_date_mode_type pretty: provide short date format t4205: cover `git log --reflog -z` blindspot pretty.c: inline initalize format_context revision: make get_revision_mark() return const pointer completion: complete `tformat:` pretty format SubmittingPatches: remove dq from commit reference pretty-formats.txt: use generic terms for hash SubmittingPatches: use generic terms for hash
2019-12-10Merge branch 'dl/submodule-set-url'Junio C Hamano
"git submodule" learned a subcommand "set-url". * dl/submodule-set-url: submodule: teach set-url subcommand