summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2020-05-14Merge branch 'ds/bloom-cleanup'Libravatar Junio C Hamano1-0/+1
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' optionsLibravatar SZEDER Gábor1-0/+1
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'Libravatar Junio C Hamano1-1/+1
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-28Merge branch 'tm/zsh-complete-switch-restore'Libravatar Junio C Hamano1-0/+2
zsh command line completion (in contrib/) update. * tm/zsh-complete-switch-restore: complete: zsh: add missing sub cmd completion candidates
2020-04-28Merge branch 'js/subtree-doc-update-to-asciidoctor-2'Libravatar Junio C Hamano1-2/+4
Doc markup update. * js/subtree-doc-update-to-asciidoctor-2: subtree: fix build with AsciiDoctor 2
2020-04-17complete: zsh: add missing sub cmd completion candidatesLibravatar Terry Moschou1-0/+2
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-08subtree: fix build with AsciiDoctor 2Libravatar Johannes Schindelin1-2/+4
This is a (late) companion for f6461b82b93 (Documentation: fix build with Asciidoctor 2, 2019-09-15). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-01completion: fix 'git add' on paths under an untracked directoryLibravatar Elijah Newren1-1/+1
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-24import-tars: ignore the global PAX headerLibravatar Johannes Schindelin1-0/+2
The tar importer in `contrib/fast-import/import-tars.perl` has a very convenient feature: if _all_ paths stored in the imported `.tar` start with a common prefix, e.g. `git-2.26.0/` in the tar at https://github.com/git/git/archive/v2.26.0.tar.gz, then this prefix is stripped. This feature makes a ton of sense because it is relatively common to import two or more revisions of the same project into Git, and obviously we don't want all files to live in a tree whose name changes from revision to revision. Now, the problem with that feature is that it breaks down if there is a `pax_global_header` "file" located outside of said prefix, at the top of the tree. This is the case for `.tar` files generated by Git's very own `git archive` command: it inserts that header, and `git archive` allows specifying a common prefix (that the header does _not_ share with the other files contained in the archive) via `--prefix=my-project-1.0.0/`. Let's just skip any global header when importing `.tar` files into Git. Note: this global header might contain useful information. For example, in the output of `git archive`, it lists the original commit, which _is_ useful information. A future improvement to the `import-tars.perl` script might be to include that information in the commit message, or do other things with the information (e.g. use `mtime` information contained in the global header as date of the commit). This patch does not prevent any future patch from making that happen, it only prevents the header from being treated as if it was a regular file. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-09Merge branch 'kk/complete-diff-color-moved'Libravatar Junio C Hamano1-0/+15
Completion update. * kk/complete-diff-color-moved: completion: add diff --color-moved[-ws]
2020-03-09Merge branch 'pb/am-show-current-patch'Libravatar Junio C Hamano1-0/+5
"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'Libravatar Junio C Hamano1-5/+1
"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]Libravatar Kir Kolyshkin1-0/+15
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/patchLibravatar Paolo Bonzini1-1/+1
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-patchLibravatar Paolo Bonzini1-0/+5
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 rebasesLibravatar Elijah Newren1-5/+1
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'Libravatar Junio C Hamano1-0/+21
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'Libravatar Junio C Hamano1-26/+93
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-checkoutLibravatar Matheus Tavares1-0/+21
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-22Merge branch 'dl/credential-netrc'Libravatar Junio C Hamano3-3/+26
Sample credential helper for using .netrc has been updated to work out of the box. * dl/credential-netrc: contrib/credential/netrc: work outside a repo contrib/credential/netrc: make PERL_PATH configurable
2020-01-16Sync with maintLibravatar Junio C Hamano1-2/+2
* maint: msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.x
2020-01-16msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.xLibravatar Johannes Schindelin1-2/+2
With the upgrade, the library names changed from libeay32/ssleay32 to libcrypto/libssl. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15completion: list paths and refs for 'git worktree add'Libravatar SZEDER Gábor1-0/+36
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' subcommandsLibravatar SZEDER Gábor1-1/+29
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 optionsLibravatar SZEDER Gábor1-22/+8
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()Libravatar SZEDER Gábor1-3/+17
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 functionLibravatar SZEDER Gábor1-5/+8
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-20contrib/credential/netrc: work outside a repoLibravatar Denton Liu1-1/+1
Currently, git-credential-netrc does not work outside of a git repository. It fails with the following error: fatal: Not a git repository: . at /usr/share/perl5/Git.pm line 214. There is no real reason why need to be within a repository, though. Credential helpers should be able to work just fine outside the repository as well. Call the non-self version of config() so that git-credential-netrc no longer needs to be run within a repository. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-20contrib/credential/netrc: make PERL_PATH configurableLibravatar Denton Liu3-2/+25
The shebang path for the Perl interpreter in git-credential-netrc was hardcoded. However, some users may have it located at a different location and thus, would have had to manually edit the script. Add a .perl prefix to the script to denote it as a template and ignore the generated version. Augment the Makefile so that it generates git-credential-netrc from git-credential-netrc.perl, just like other Perl scripts. The Makefile recipes were shamelessly stolen from contrib/mw-to-git/Makefile. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-10Merge branch 'dl/pretty-reference'Libravatar Junio C Hamano1-1/+1
"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'Libravatar Junio C Hamano1-1/+1
"git submodule" learned a subcommand "set-url". * dl/submodule-set-url: submodule: teach set-url subcommand
2019-12-01Merge branch 'js/complete-svn-recursive'Libravatar Junio C Hamano1-0/+1
The completion script (in contrib/) has been taught that "git svn" supports the "--recursive" option. * js/complete-svn-recursive: completion: tab-complete "git svn --recursive"
2019-12-01Merge branch 'dl/complete-rebase-onto'Libravatar Junio C Hamano1-0/+4
The completion script (in contrib/) learned that the "--onto" option of "git rebase" can take its argument as the value of the option. * dl/complete-rebase-onto: completion: learn to complete `git rebase --onto=`
2019-12-01Merge branch 'jk/remove-sha1-to-hex'Libravatar Junio C Hamano1-32/+0
Code clean-up. * jk/remove-sha1-to-hex: hex: drop sha1_to_hex() hex: drop sha1_to_hex_r()
2019-11-20pretty: implement 'reference' formatLibravatar Denton Liu1-1/+1
The standard format for referencing other commits within some projects (such as git.git) is the reference format. This is described in Documentation/SubmittingPatches as If you want to reference a previous commit in the history of a stable branch, use the format "abbreviated hash (subject, date)", like this: .... Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30) noticed that ... .... Since this format is so commonly used, standardize it as a pretty format. The tests that are implemented essentially show that the format-string does not change in response to various log options. This is useful because, for future developers, it shows that we've considered the limitations of the "canned format-string" approach and we are fine with them. Based-on-a-patch-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-20completion: complete `tformat:` pretty formatLibravatar Denton Liu1-1/+1
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13completion: tab-complete "git svn --recursive"Libravatar James Shubin1-0/+1
Signed-off-by: James Shubin <james@shubin.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13hex: drop sha1_to_hex()Libravatar Jeff King1-15/+0
There's only a single caller left of sha1_to_hex(), since everybody that has an object name in "unsigned char[]" now uses hash_to_hex() instead. This case is in the sha1dc wrapper, where we print a hex sha1 when we find a collision. This one will always be sha1, regardless of the current hash algorithm, so we can't use hash_to_hex() here. In practice we'd probably not be running sha1 at all if it isn't the current algorithm, but it's possible we might still occasionally need to compute a sha1 in a post-sha256 world. Since sha1_to_hex() is just a wrapper for hash_to_hex_algop(), let's call that ourselves. There's value in getting rid of the sha1-specific wrapper to de-clutter the global namespace, and to make sure nobody uses it (and as with sha1_to_hex_r() in the previous patch, we'll drop the coccinelle transformations, too). The sha1_to_hex() function is mentioned in a comment; we can easily swap that out for oid_to_hex() to give a better example. Also update the comment that was left stale when we added "struct object_id *" as a way to name an object and added functions to convert it to hex. The function is also mentioned in some test vectors in t4100, but that's not runnable code, so there's no point in trying to clean it up. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12completion: learn to complete `git rebase --onto=`Libravatar Denton Liu1-0/+4
In 2b9bd488ae ("completion: teach rebase to use __gitcomp_builtin", 2019-09-12), the completion script learned to complete rebase using __gitcomp_builtin(). However, this resulted in `--onto=` being suggested instead of `--onto `. Before, when there was a space, we'd start a new word and, as a result, fallback to __git_complete_refs() and `--onto` would be completed this way. However, now we match the `--*` case which does not know how to offer completions for refs. Teach _git_rebase() to complete refs in the `--onto=` case so that we fix this regression. Reported-by: Paul Jolly <paul@myitcv.io> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11hex: drop sha1_to_hex_r()Libravatar Jeff King1-17/+0
There are no callers left; everybody uses oid_to_hex_r() or hash_to_hex_algop_r(). This used to actually be the underlying implementation for oid_to_hex_r(), but that's no longer the case since 47edb64997 (hex: introduce functions to print arbitrary hashes, 2018-11-14). Let's get rid of it to de-clutter and to make sure nobody uses it. Likewise we can drop the coccinelle rules that mention it, since the compiler will make it quite clear that the code does not work. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Fix spelling errors in no-longer-updated-from-upstream modulesLibravatar Elijah Newren5-5/+5
We have several modules originally taken from some upstream source, and which as far as I can tell we no longer update from the upstream anymore. As such, I have not submitted these spelling fixes to any external projects but just include them directly here. Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10multimail: fix a few simple spelling errorsLibravatar Elijah Newren2-5/+5
Also submitted upstream as: https://github.com/git-multimail/git-multimail/pull/208 Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Fix spelling errors in messages shown to usersLibravatar Elijah Newren1-1/+1
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Fix spelling errors in code commentsLibravatar Elijah Newren3-4/+4
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-07Fix spelling errors in documentation outside of Documentation/Libravatar Elijah Newren1-1/+1
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-30submodule: teach set-url subcommandLibravatar Denton Liu1-1/+1
Currently, in the event that a submodule's upstream URL changes, users have to manually alter the URL in the .gitmodules file then run `git submodule sync`. Let's make that process easier. Teach submodule the set-url subcommand which will automatically change the `submodule.$name.url` property in the .gitmodules file and then run `git submodule sync` to complete the process. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23Merge branch 'nr/diff-highlight-indent-fix'Libravatar Junio C Hamano1-1/+1
Code cleanup. * nr/diff-highlight-indent-fix: diff-highlight: fix a whitespace nit
2019-10-23Merge branch 'mb/clarify-zsh-completion-doc'Libravatar Junio C Hamano1-2/+3
The installation instruction for zsh completion script (in contrib/) has been a bit improved. * mb/clarify-zsh-completion-doc: completion: clarify installation instruction for zsh
2019-10-18completion: clarify installation instruction for zshLibravatar Maxim Belsky1-2/+3
The original comment does not describe type of ~/.zsh/_git explicitly and zsh does not warn or fail if a user create it as a dictionary. So unexperienced users could be misled by the original comment. There is a small update to clarify it. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Maxim Belsky <public.belsky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15diff-highlight: fix a whitespace nitLibravatar Norman Rasmussen1-1/+1
This changes the indent from "<tab><sp><sp><sp><sp><sp><sp><sp><sp>" to "<tab><tab>" so that the statement lines up with the rest of the block. Signed-off-by: Norman Rasmussen <norman@rasmussen.co.za> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>