summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
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>
2019-10-15Merge branch 'ew/hashmap'Libravatar Junio C Hamano1-0/+16
Code clean-up of the hashmap API, both users and implementation. * ew/hashmap: hashmap_entry: remove first member requirement from docs hashmap: remove type arg from hashmap_{get,put,remove}_entry OFFSETOF_VAR macro to simplify hashmap iterators hashmap: introduce hashmap_free_entries hashmap: hashmap_{put,remove} return hashmap_entry * hashmap: use *_entry APIs for iteration hashmap_cmp_fn takes hashmap_entry params hashmap_get{,_from_hash} return "struct hashmap_entry *" hashmap: use *_entry APIs to wrap container_of hashmap_get_next returns "struct hashmap_entry *" introduce container_of macro hashmap_put takes "struct hashmap_entry *" hashmap_remove takes "const struct hashmap_entry *" hashmap_get takes "const struct hashmap_entry *" hashmap_add takes "struct hashmap_entry *" hashmap_get_next takes "const struct hashmap_entry *" hashmap_entry_init takes "struct hashmap_entry *" packfile: use hashmap_entry in delta_base_cache_entry coccicheck: detect hashmap_entry.hash assignment diff: use hashmap_entry_init on moved_entry.ent
2019-10-15Merge branch 'js/azure-pipelines-msvc'Libravatar Junio C Hamano1-0/+3
CI updates. * js/azure-pipelines-msvc: ci: also build and test with MS Visual Studio on Azure Pipelines ci: really use shallow clones on Azure Pipelines tests: let --immediate and --write-junit-xml play well together test-tool run-command: learn to run (parts of) the testsuite vcxproj: include more generated files vcxproj: only copy `git-remote-http.exe` once it was built msvc: work around a bug in GetEnvironmentVariable() msvc: handle DEVELOPER=1 msvc: ignore some libraries when linking compat/win32/path-utils.h: add #include guards winansi: use FLEX_ARRAY to avoid compiler warning msvc: avoid using minus operator on unsigned types push: do not pretend to return `int` from `die_push_simple()`
2019-10-09Merge branch 'am/visual-studio-config-fix'Libravatar Junio C Hamano1-7/+8
Dev support. * am/visual-studio-config-fix: contrib/buildsystems: fix Visual Studio Debug configuration
2019-10-07Merge branch 'cc/svn-fe-py-shebang'Libravatar Junio C Hamano1-1/+1
* cc/svn-fe-py-shebang: contrib/svn-fe: fix shebang for svnrdump_sim.py
2019-10-07Merge branch 'hb/hg-to-git-py3'Libravatar Junio C Hamano1-25/+25
The hg-to-git script (in contrib/) has been updated to work with Python 3. * hb/hg-to-git-py3: hg-to-git: make it compatible with both python3 and python2
2019-10-07Merge branch 'mr/complete-more-for-log-etc'Libravatar Junio C Hamano1-4/+14
Completion updates. * mr/complete-more-for-log-etc: completion: add missing completions for log, diff, show
2019-10-07Merge branch 'dl/complete-rebase-and-archive'Libravatar Junio C Hamano1-19/+8
The command line completion for "git archive" and "git rebase" are now made less prone to go out of sync with the binary. * dl/complete-rebase-and-archive: completion: teach archive to use __gitcomp_builtin completion: teach rebase to use __gitcomp_builtin
2019-10-07coccicheck: detect hashmap_entry.hash assignmentLibravatar Eric Wong1-0/+16
Assigning hashmap_entry.hash manually leaves hashmap_entry.next uninitialized, which can be dangerous once the hashmap_entry is inserted into a hashmap. Detect those assignments and use hashmap_entry_init, instead. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-06vcxproj: only copy `git-remote-http.exe` once it was builtLibravatar Johannes Schindelin1-0/+3
In b18ae14a8f6 (vcxproj: also link-or-copy builtins, 2019-07-29), we started to copy or hard-link the built-ins as a post-build step of the `git` project. At the same time, we tried to copy or hard-link `git-remote-http.exe`, but it is quite possible that it was not built at that time. Let's move that latter task into a post-install step of the `git-remote-http` project instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-30Merge branch 'dl/rebase-i-keep-base'Libravatar Junio C Hamano1-1/+1
"git rebase --keep-base <upstream>" tries to find the original base of the topic being rebased and rebase on top of that same base, which is useful when running the "git rebase -i" (and its limited variant "git rebase -x"). The command also has learned to fast-forward in more cases where it can instead of replaying to recreate identical commits. * dl/rebase-i-keep-base: rebase: teach rebase --keep-base rebase tests: test linear branch topology rebase: fast-forward --fork-point in more cases rebase: fast-forward --onto in more cases rebase: refactor can_fast_forward into goto tower t3432: test for --no-ff's interaction with fast-forward t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests t3432: test rebase fast-forward behavior t3431: add rebase --fork-point tests
2019-09-30Merge branch 'dl/complete-cherry-pick-revert-skip'Libravatar Junio C Hamano1-2/+4
The command line completion support (in contrib/) learned about the "--skip" option of "git revert" and "git cherry-pick". * dl/complete-cherry-pick-revert-skip: status: mention --skip for revert and cherry-pick completion: add --skip for cherry-pick and revert completion: merge options for cherry-pick and revert
2019-09-30Merge branch 'en/filter-branch-deprecation'Libravatar Junio C Hamano1-2/+2
Start discouraging the use of "git filter-branch". * en/filter-branch-deprecation: t9902: use a non-deprecated command for testing Recommend git-filter-repo instead of git-filter-branch t6006: simplify, fix, and optimize empty message test
2019-09-28contrib/buildsystems: fix Visual Studio Debug configurationLibravatar Alexandr Miloslavskiy1-7/+8
Even though Debug configuration builds, the resulting build is incorrect in a subtle way: it mixes up Debug and Release binaries, which in turn causes hard-to-predict bugs. In my case, when git calls iconv library, iconv sets 'errno' and git then tests it, but in Debug and Release CRT those 'errno' are different memory locations. This patch addresses 3 connected bugs: 1) Typo in '\(Configuration)'. As a result, Debug configuration condition is always false and Release path is taken instead. 2) Regexp that replaced 'zlib.lib' with 'zlibd.lib' was only affecting the first occurrence. However, some projects have it listed twice. Previously this bug was hidden, because Debug path was never taken. I decided that avoiding double -lz in makefile is fragile and I'd better replace all occurrences instead. 3) In Debug, 'libcurl-d.lib' should be used instead of 'libcurl.lib'. Previously this bug was hidden, because Debug path was never taken. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-18hg-to-git: make it compatible with both python3 and python2Libravatar Hervé Beraud1-25/+25
Python 2 is EOL at the end of 2019, many distros and systems now come with python 3 as their default version. Rewrite features used in hg-to-git that are no longer supported in Python 3, in such a way that an updated code can still be usable with Python 2: - print is not a statement; use print() function instead. - dict.has_key(key) is no more; use "key in dict" instead. Signed-off-by: Hervé Beraud <herveberaud.pro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-18contrib/svn-fe: fix shebang for svnrdump_sim.pyLibravatar Clément Chigot1-1/+1
The shebang for a python script should be "/usr/bin/env python" and not "/usr/bin/python". On some OSes like AIX, python default path is not under "/usr/bin" ("/opt/freeware/bin" for AIX). Note the main reason behind this change is that AIX rpm will add a dependency on "/usr/bin/python" instead of "/usr/bin/env". Signed-off-by: Clément Chigot <clement.chigot@atos.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-12completion: teach archive to use __gitcomp_builtinLibravatar Denton Liu1-4/+1
Currently, _git_archive() uses a hardcoded list of options for its completion. However, we can use __gitcomp_builtin() to get a dynamically generated list of completions instead. Teach _git_archive() to use __gitcomp_builtin() so that newly implemented options in archive will be automatically completed without any mucking around in git-completion.bash. While we're at it, teach it to complete the missing `--worktree-attributes` option as well. Unfortunately, since some args are passed through from cmd_archive() to write_archive() (which calls parse_archive_args()), there's no way that a `--git-completion-helper` arg can end up reaching parse_archive_args() since the first call to parse_options() will end up calling exit(0). As a result, we have to carry the options supported by write_archive() in the hardcoded string. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-12completion: teach rebase to use __gitcomp_builtinLibravatar Denton Liu1-15/+7
Currently, _git_rebase() uses a hardcoded list of options for its completion. However, we can use __gitcomp_builtin() to get a dynamically generated list of completions instead. Teach _git_rebase() to use __gitcomp_builtin() so that newly implemented options in rebase will be automatically completed without any mucking around in git-completion.bash. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-12completion: add missing completions for log, diff, showLibravatar Max Rothman1-4/+14
The bash completion script knows some options to "git log" and "git show" only in the positive form, (e.g. "--abbrev-commit"), but not in their negative form (e.g. "--no-abbrev-commit"). Add them. Also, the bash completion script is missing some other options to "git diff", and "git show" (and thus, all other commands that take "git diff"'s options). Add them. Of note, since "--indent-heuristic" is no longer experimental, add that too. Signed-off-by: Max Rothman <max.r.rothman@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05Recommend git-filter-repo instead of git-filter-branchLibravatar Elijah Newren1-2/+2
filter-branch suffers from a deluge of disguised dangers that disfigure history rewrites (i.e. deviate from the deliberate changes). Many of these problems are unobtrusive and can easily go undiscovered until the new repository is in use. This can result in problems ranging from an even messier history than what led folks to filter-branch in the first place, to data loss or corruption. These issues cannot be backward compatibly fixed, so add a warning to both filter-branch and its manpage recommending that another tool (such as filter-repo) be used instead. Also, update other manpages that referenced filter-branch. Several of these needed updates even if we could continue recommending filter-branch, either due to implying that something was unique to filter-branch when it applied more generally to all history rewriting tools (e.g. BFG, reposurgeon, fast-import, filter-repo), or because something about filter-branch was used as an example despite other more commonly known examples now existing. Reword these sections to fix these issues and to avoid recommending filter-branch. Finally, remove the section explaining BFG Repo Cleaner as an alternative to filter-branch. I feel somewhat bad about this, especially since I feel like I learned so much from BFG that I put to good use in filter-repo (which is much more than I can say for filter-branch), but keeping that section presented a few problems: * In order to recommend that people quit using filter-branch, we need to provide them a recomendation for something else to use that can handle all the same types of rewrites. To my knowledge, filter-repo is the only such tool. So it needs to be mentioned. * I don't want to give conflicting recommendations to users * If we recommend two tools, we shouldn't expect users to learn both and pick which one to use; we should explain which problems one can solve that the other can't or when one is much faster than the other. * BFG and filter-repo have similar performance * All filtering types that BFG can do, filter-repo can also do. In fact, filter-repo comes with a reimplementation of BFG named bfg-ish which provides the same user-interface as BFG but with several bugfixes and new features that are hard to implement in BFG due to its technical underpinnings. While I could still mention both tools, it seems like I would need to provide some kind of comparison and I would ultimately just say that filter-repo can do everything BFG can, so ultimately it seems that it is just better to remove that section altogether. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27rebase: teach rebase --keep-baseLibravatar Denton Liu1-1/+1
A common scenario is if a user is working on a topic branch and they wish to make some changes to intermediate commits or autosquash, they would run something such as git rebase -i --onto master... master in order to preserve the merge base. This is useful when contributing a patch series to the Git mailing list, one often starts on top of the current 'master'. While developing the patches, 'master' is also developed further and it is sometimes not the best idea to keep rebasing on top of 'master', but to keep the base commit as-is. In addition to this, a user wishing to test individual commits in a topic branch without changing anything may run git rebase -x ./test.sh master... master Since rebasing onto the merge base of the branch and the upstream is such a common case, introduce the --keep-base option as a shortcut. This allows us to rewrite the above as git rebase -i --keep-base master and git rebase -x ./test.sh --keep-base master respectively. Add tests to ensure --keep-base works correctly in the normal case and fails when there are multiple merge bases, both in regular and interactive mode. Also, test to make sure conflicting options cause rebase to fail. While we're adding test cases, add a missing set_fake_editor call to 'rebase -i --onto master...side'. While we're documenting the --keep-base option, change an instance of "merge-base" to "merge base", which is the consistent spelling. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27completion: add --skip for cherry-pick and revertLibravatar Denton Liu1-1/+1
Even though `--skip` is a valid command-line option for cherry-pick and revert while they are in progress, it is not completed. Add this missing option to the completion script. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27completion: merge options for cherry-pick and revertLibravatar Denton Liu1-2/+4
Since revert and cherry-pick share the same sequencer code, they should both accept the same command-line options. Derive the `__git_cherry_pick_inprogress_options` and `__git_revert_inprogress_options` variables from `__git_sequencer_inprogress_options` so that the options aren't unnecessarily duplicated twice. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete config variables and values for 'git clone --config='Libravatar SZEDER Gábor1-17/+49
Completing configuration sections and variable names for the stuck argument of 'git clone --config=<TAB>' requires a bit of extra care compared to doing the same for the unstuck argument of 'git clone --config <TAB>', because we have to deal with that '--config=' being part of the current word to be completed. Add an option to the __git_complete_config_variable_name_and_value() and in turn to the __git_complete_config_variable_name() helper functions to specify the current section/variable name to be completed, so they can be used even when completing the stuck argument of '--config='. __git_complete_config_variable_value() already has such an option, and thus no further changes were necessary to complete possible values after 'git clone --config=section.name=<TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete config variables names and values for 'git clone -c'Libravatar SZEDER Gábor1-0/+6
The previous commits taught the completion script how to complete configuration section, variable names, and their valus after 'git -c <TAB>', and with a bit of foresight encapsulated all that in a dedicated helper function. Use that function to complete the unstuck argument of 'git config -c|--config <TAB>', which expect configuration variables and values in the same 'section.name=value' form. Note that handling the struck argument for 'git clone --config=<TAB>' requires some extra care, so it will be done a separate patch. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete values of configuration variables after 'git -c var='Libravatar SZEDER Gábor1-24/+41
'git config' expects a configuration variable's name and value in separate options, so we complete values as they stand on their own on the command line. 'git -c', however, expects them in a single option joined by a '=' character, so we should be able to complete values when they are following 'section.name=' in the same word. Add new options to the __git_complete_config_variable_value() function to allow callers to specify the current word to be completed and the configuration variable whose value is to be completed, and use these to complete possible values after 'git -c 'section.name=<TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete configuration sections and variable names for 'git -c'Libravatar SZEDER Gábor1-13/+46
'git config' expects a configuration variable's name and value in separate arguments, so we let the __gitcomp() helper append a space character to each variable name by default, like we do for most other things (--options, refs, paths, etc.). 'git -c', however, expects them in a single option joined by a '=' character, i.e. 'section.name=value', so we should append a '=' character to each fully completed variable name, but no space, so the user can continue typing the value right away. Add an option to the __git_complete_config_variable_name() function to allow callers to specify an alternate suffix to add, and use it to append that '=' character to configuration variables. Update the __gitcomp() helper function to not append a trailing space to any completion words ending with a '=', not just to those option with a stuck argument. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: split _git_config()Libravatar SZEDER Gábor1-9/+30
_git_config() contains two enormous case statements, one to complete configuration sections and variable names, and the other to complete their values. Split these out into two separate helper functions, so in the next patches we can use them to implement completion for 'git -c <TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: simplify inner 'case' pattern in __gitcomp()Libravatar SZEDER Gábor1-2/+2
The second '*' in the '--*=*' pattern of the inner 'case' statement of the __gitcomp() helper function never matches anything, so let's use '--*=' instead. The purpose of that inner case statement is to decide when to append a trailing space to the listed options and when not. When an option requires a stuck argument, i.e. '--option=', then the trailing space should not be added, so the user can continue typing the required argument right away. That '--*=*' pattern is supposed to match these options, but for this purpose that second '*' is unnecessary, a '--*=' pattern works just as well. That second '*' would only make a difference in case of a possible completion word like '--option=value', but our completion script never passes such a word to __gitcomp(), because the '--option=' and its 'value' must be completed separately. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: use 'sort -u' to deduplicate config variable namesLibravatar SZEDER Gábor1-1/+1
The completion script runs the classic '| sort | uniq' pipeline to deduplicate the output of 'git help --config-for-completion'. 'sort -u' does the same, but uses one less external process and pipeline stage. Not a bit win, as it's only run once as the list of supported configuration variables is initialized, but at least it sets a better example for others to follow. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>