summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2019-04-22Merge branch 'da/smerge'Libravatar Junio C Hamano1-1/+2
"git mergetool" learned to offer Sublime Merge (smerge) as one of its backends. * da/smerge: contrib/completion: add smerge to the mergetool completion candidates mergetools: add support for smerge (Sublime Merge)
2019-04-22Merge branch 'dl/flex-str-cocci'Libravatar Junio C Hamano1-0/+13
Code clean-up. * dl/flex-str-cocci: cocci: FLEX_ALLOC_MEM to FLEX_ALLOC_STR midx.c: convert FLEX_ALLOC_MEM to FLEX_ALLOC_STR
2019-04-16Merge branch 'tz/completion'Libravatar Junio C Hamano1-4/+4
The completion helper code now pays attention to repository-local configuration (when available), which allows --list-cmds to honour a repository specific setting of completion.commands, for example. * tz/completion: completion: use __git when calling --list-cmds completion: fix multiple command removals t9902: test multiple removals via completion.commands git: read local config in --list-cmds
2019-04-04cocci: FLEX_ALLOC_MEM to FLEX_ALLOC_STRLibravatar Denton Liu1-0/+13
Ensure that a FLEX_MALLOC_MEM that uses 'strlen' for its 'len' uses FLEX_ALLOC_STR instead, since these are equivalent forms. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-04contrib/completion: add smerge to the mergetool completion candidatesLibravatar David Aguilar1-1/+2
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-21completion: use __git when calling --list-cmdsLibravatar Todd Zullinger1-4/+4
As we made --list-cmds read the local configuration file in an earlier step, the completion.commands variable respects repo-level configuration. Use __git which ensures that the proper repo config is consulted if the command line contains 'git -C /some/other/repo'. Suggested-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-12contrib/subtree: ensure only one rev is providedLibravatar Denton Liu1-12/+12
While looking at the inline help for git-subtree.sh, I noticed that git subtree split --prefix=<prefix> <commit...> was given as an option. However, it only really makes sense to provide one revision because of the way the commits are forwarded to rev-parse so change "<commit...>" to "<commit>" to reflect this. In addition, check the arguments to ensure that only one rev is provided for all subcommands that accept a commit. Signed-off-by: Denton Liu <liu.denton@gmail.com> Acked-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07Merge branch 'nd/completion-more-parameters'Libravatar Junio C Hamano1-3/+40
The command line completion (in contrib/) has been taught to complete more subcommand parameters. * nd/completion-more-parameters: completion: add more parameter value completion
2019-03-07Merge branch 'dl/complete-submodule-absorbgitdirs'Libravatar Junio C Hamano1-1/+1
Command-line completion (in contrib/) learned to tab-complete the "git submodule absorbgitdirs" subcommand. * dl/complete-submodule-absorbgitdirs: completion: complete git submodule absorbgitdirs
2019-02-20completion: add more parameter value completionLibravatar Nguyễn Thái Ngọc Duy1-3/+40
This adds value completion for a couple more paramters. To make it easier to maintain these hard coded lists, add a comment at the original list/code to remind people to update git-completion.bash too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-06completion: complete git submodule absorbgitdirsLibravatar Denton Liu1-1/+1
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-05Merge branch 'sg/strbuf-addbuf-cocci'Libravatar Junio C Hamano1-0/+30
Cocci rule update. * sg/strbuf-addbuf-cocci: strbuf.cocci: suggest strbuf_addbuf() to add one strbuf to an other
2019-02-05Merge branch 'sb/more-repo-in-api'Libravatar Junio C Hamano1-0/+144
The in-core repository instances are passed through more codepaths. * sb/more-repo-in-api: (23 commits) t/helper/test-repository: celebrate independence from the_repository path.h: make REPO_GIT_PATH_FUNC repository agnostic commit: prepare free_commit_buffer and release_commit_memory for any repo commit-graph: convert remaining functions to handle any repo submodule: don't add submodule as odb for push submodule: use submodule repos for object lookup pretty: prepare format_commit_message to handle arbitrary repositories commit: prepare logmsg_reencode to handle arbitrary repositories commit: prepare repo_unuse_commit_buffer to handle any repo commit: prepare get_commit_buffer to handle any repo commit-reach: prepare in_merge_bases[_many] to handle any repo commit-reach: prepare get_merge_bases to handle any repo commit-reach.c: allow get_merge_bases_many_0 to handle any repo commit-reach.c: allow remove_redundant to handle any repo commit-reach.c: allow merge_bases_many to handle any repo commit-reach.c: allow paint_down_to_common to handle any repo commit: allow parse_commit* to handle any repo object: parse_object to honor its repository argument object-store: prepare has_{sha1, object}_file to handle any repo object-store: prepare read_object_file to deal with any repo ...
2019-01-29Merge branch 'bc/tree-walk-oid'Libravatar Junio C Hamano1-30/+0
The code to walk tree objects has been taught that we may be working with object names that are not computed with SHA-1. * bc/tree-walk-oid: cache: make oidcpy always copy GIT_MAX_RAWSZ bytes tree-walk: store object_id in a separate member match-trees: use hashcpy to splice trees match-trees: compute buffer offset correctly when splicing tree-walk: copy object ID before use
2019-01-27strbuf.cocci: suggest strbuf_addbuf() to add one strbuf to an otherLibravatar SZEDER Gábor1-0/+30
The best way to add one strbuf to an other is via: strbuf_addbuf(&sb, &sb2); This is a bit more idiomatic and efficient than: strbuf_addstr(&sb, sb2.buf); because the size of the second strbuf is known and thus it can spare a strlen() call, and much more so than: strbuf_addf(&sb, "%s", sb2.buf); because it can spare the whole vsnprintf() formatting magic. Add new semantic patches to 'contrib/coccinelle/strbuf.cocci' to catch these undesired patterns and to suggest strbuf_addbuf() instead. Luckily, our codebase is already clean from any such undesired patterns (but one of the in-flight topics just tried to sneak in such a strbuf_addf() call). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-18Merge branch 'mm/multimail-1.5'Libravatar Junio C Hamano8-57/+281
Update "git multimail" from the upstream. * mm/multimail-1.5: git-multimail: update to release 1.5.0
2019-01-18Merge branch 'cy/zsh-completion-SP-in-path'Libravatar Junio C Hamano2-23/+16
With zsh, "git cmd path<TAB>" was completed to "git cmd path name" when the completed path has a special character like SP in it, without any attempt to keep "path name" a single filename. This has been fixed to complete it to "git cmd path\ name" just like Bash completion does. * cy/zsh-completion-SP-in-path: completion: treat results of git ls-tree as file paths zsh: complete unquoted paths with spaces correctly
2019-01-15cache: make oidcpy always copy GIT_MAX_RAWSZ bytesLibravatar brian m. carlson1-30/+0
There are some situations in which we want to store an object ID into struct object_id without the_hash_algo necessarily being set correctly. One such case is when cloning a repository, where we must read refs from the remote side without having a repository from which to read the preferred algorithm. In this cases, we may have the_hash_algo set to SHA-1, which is the default, but read refs into struct object_id that are SHA-256. When copying these values, we will want to copy them completely, not just the first 20 bytes. Consequently, make sure that oidcpy copies the maximum number of bytes at all times, regardless of the setting of the_hash_algo. Since oidcpy and hashcpy are no longer functionally identical, remove the Cocinelle object_id transformations that convert from one into the other. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07git-multimail: update to release 1.5.0Libravatar Matthieu Moy8-57/+281
Changes are described in CHANGES. Contributions-by: Matthieu Moy <git@matthieu-moy.fr> Contributions-by: William Stewart <william.stewart@booking.com> Contributions-by: Ville Skyttä <ville.skytta@iki.fi> Contributions-by: Dirk Olmes <dirk.olmes@codedo.de> Contributions-by: Björn Kautler <Bjoern@Kautler.net> Contributions-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Contributions-by: Gareth Pye <garethp@gpsatsys.com.au> Contributions-by: David Lazar <lazard@csail.mit.edu> Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-03completion: fix typo in git-completion.bashLibravatar Chayoung You1-1/+1
Signed-off-by: Chayoung You <yousbe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-03completion: treat results of git ls-tree as file pathsLibravatar Chayoung You1-19/+12
Let's say there are files named 'foo bar.txt', and 'abc def/test.txt' in repository. When following commands trigger a completion: git show HEAD:fo<Tab> git show HEAD:ab<Tab> The completion results in bash/zsh: git show HEAD:foo bar.txt git show HEAD:abc def/ Where the both of them have an unescaped space in paths, so they'll be misread by git. All entries of git ls-tree either a filename or a directory, so __gitcomp_file() is proper rather than __gitcomp_nl(). Note the commit f12785a3, which handles quoted paths properly. Like this case, we should dequote $cur_ for ?*:* case. For example, let's say there is untracked directory 'abc deg', then trigger a completion: git show HEAD:abc\ de<Tab> git show HEAD:'abc de<Tab> git show HEAD:"abc de<Tab> should uniquely complete 'abc def', but bash completes 'abc def' and 'abc deg' instead. In zsh, triggering a completion: git show HEAD:abc\ def/<Tab> should complete 'test.txt', but nothing comes. The both problems will be resolved by dequoting paths. __git_complete_revlist_file() passes arguments to __gitcomp_nl() where the first one is a list something like: abc def/Z foo bar.txt Z where Z is the mark of the EOL. - The trailing space of blob in __git ls-tree | sed. It makes the completion results become: git show HEAD:foo\ bar.txt\ <CURSOR> So git will try to find a file named 'foo bar.txt ' instead. - The trailing slash of tree in __git ls-tree | sed. It makes the completion results on zsh become: git show HEAD:abc\ def/ <CURSOR> So that the last space on command like should be removed on zsh to complete filenames under 'abc def/'. Signed-off-by: Chayoung You <yousbe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-03zsh: complete unquoted paths with spaces correctlyLibravatar Chayoung You2-4/+4
The following is the description of -Q flag of zsh compadd [1]: This flag instructs the completion code not to quote any metacharacters in the words when inserting them into the command line. Let's say there is a file named 'foo bar.txt' in repository, but it's not yet added to the repository. Then the following command triggers a completion: git add fo<Tab> git add 'fo<Tab> git add "fo<Tab> The completion results in bash: git add foo\ bar.txt git add 'foo bar.txt' git add "foo bar.txt" While them in zsh: git add foo bar.txt git add 'foo bar.txt' git add "foo bar.txt" The first one, where the pathname is not enclosed in quotes, should escape the space with a backslash, just like bash completion does. Otherwise, this leads git to think there are two files; foo, and bar.txt. The main cause of this behavior is __gitcomp_file_direct(). The both implementions of bash and zsh are called with an argument 'foo bar.txt', but only bash adds a backslash before a space on command line. [1]: http://zsh.sourceforge.net/Doc/Release/Completion-Widgets.html Signed-off-by: Chayoung You <yousbe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19Merge branch 'sb/cocci-pending'Libravatar Junio C Hamano1-0/+41
A coding convention around the Coccinelle semantic patches to have two classes to ease code migration process has been proposed and its support has been added to the Makefile. * sb/cocci-pending: coccicheck: introduce 'pending' semantic patches
2018-11-14pretty: prepare format_commit_message to handle arbitrary repositoriesLibravatar Stefan Beller1-0/+10
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit: prepare logmsg_reencode to handle arbitrary repositoriesLibravatar Stefan Beller1-0/+9
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit: prepare repo_unuse_commit_buffer to handle any repoLibravatar Stefan Beller1-0/+8
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit: prepare get_commit_buffer to handle any repoLibravatar Stefan Beller1-0/+8
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit-reach: prepare in_merge_bases[_many] to handle any repoLibravatar Stefan Beller1-0/+17
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit-reach: prepare get_merge_bases to handle any repoLibravatar Stefan Beller1-0/+26
Similarly to previous patches, the get_merge_base functions are used often in the code base, which makes migrating them hard. Implement the new functions, prefixed with 'repo_' and hide the old functions behind a wrapper macro. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit: allow parse_commit* to handle any repoLibravatar Stefan Beller1-0/+24
Just like the previous commit, parse_commit and friends are used a lot and are found in new patches, so we cannot change their signature easily. Re-introduce these function prefixed with 'repo_' that take a repository argument and keep the original as a shallow macro. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14object-store: prepare has_{sha1, object}_file to handle any repoLibravatar Stefan Beller1-0/+30
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14object-store: prepare read_object_file to deal with any repoLibravatar Stefan Beller1-0/+12
As read_object_file is a widely used function (which is also regularly used in new code in flight between master..pu), changing its signature is painful is hard, as other series in flight rely on the original signature. It would burden the maintainer if we'd just change the signature. Introduce repo_read_object_file which takes the repository argument, and hide the original read_object_file as a macro behind NO_THE_REPOSITORY_COMPATIBILITY_MACROS, similar to e675765235 (diff.c: remove implicit dependency on the_index, 2018-09-21) Add a coccinelle patch to convert existing callers, but do not apply the resulting patch to keep the diff of this patch small. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14coccicheck: introduce 'pending' semantic patchesLibravatar SZEDER Gábor1-0/+41
Teach `make coccicheck` to avoid patches named "*.pending.cocci" and handle them separately in a new `make coccicheck-pending` instead. This means that we can separate "critical" patches from "FYI" patches. The former target can continue causing Travis to fail its static analysis job, while the latter can let us keep an eye on ongoing (pending) transitions without them causing too much fallout. Document the intended use-cases around these two targets. As the process around the pending patches is not yet fully explored, leave that out. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Based-on-work-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13Merge branch 'nd/complete-format-patch'Libravatar Junio C Hamano1-10/+6
The support for format-patch (and send-email) by the command-line completion script (in contrib/) has been simplified a bit. * nd/complete-format-patch: completion: use __gitcomp_builtin for format-patch
2018-11-06Merge branch 'nd/completion-negation'Libravatar Junio C Hamano1-1/+1
The command line completion machinery (in contrib/) has been updated to allow the completion script to tweak the list of options that are reported by the parse-options machinery correctly. * nd/completion-negation: completion: fix __gitcomp_builtin no longer consider extra options
2018-11-06completion: use __gitcomp_builtin for format-patchLibravatar Duy Nguyen1-10/+6
This helps format-patch gain completion for a couple new options, notably --range-diff. Since send-email completion relies on $__git_format_patch_options which is now reduced, we need to do something not to regress send-email completion. The workaround here is implement --git-completion-helper in send-email.perl just as a bridge to "format-patch --git-completion-helper". This is enough to use __gitcomp_builtin on send-email (to take advantage of caching). In the end, send-email.perl can probably reuse the same info it passes to GetOptions() to generate full --git-completion-helper output so that we don't need to keep track of its options in git-completion.bash anymore. But that's something for another boring day. Helped-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-30Merge branch 'dl/mergetool-gui-option'Libravatar Junio C Hamano1-1/+1
"git mergetool" learned to take the "--[no-]gui" option, just like "git difftool" does. * dl/mergetool-gui-option: doc: document diff/merge.guitool config keys completion: support `git mergetool --[no-]gui` mergetool: accept -g/--[no-]gui as arguments
2018-10-30Merge branch 'js/mingw-load-sys-dll'Libravatar Junio C Hamano1-1/+2
The way DLLs are loaded on the Windows port has been improved. * js/mingw-load-sys-dll: mingw: load system libraries the recommended way
2018-10-30Merge branch 'jc/cocci-preincr'Libravatar Junio C Hamano1-0/+5
Code cleanup. * jc/cocci-preincr: fsck: s/++i > 1/i++/ cocci: simplify "if (++u > 1)" to "if (u++)"
2018-10-30Merge branch 'bc/hash-transition-part-15'Libravatar Junio C Hamano1-54/+63
More codepaths are moving away from hardcoded hash sizes. * bc/hash-transition-part-15: rerere: convert to use the_hash_algo submodule: make zero-oid comparison hash function agnostic apply: rename new_sha1_prefix and old_sha1_prefix apply: replace hard-coded constants tag: express constant in terms of the_hash_algo transport: use parse_oid_hex instead of a constant upload-pack: express constants in terms of the_hash_algo refs/packed-backend: express constants using the_hash_algo packfile: express constants in terms of the_hash_algo pack-revindex: express constants in terms of the_hash_algo builtin/fetch-pack: remove constants with parse_oid_hex builtin/mktree: remove hard-coded constant builtin/repack: replace hard-coded constants pack-bitmap-write: use GIT_MAX_RAWSZ for allocation object_id.cocci: match only expressions of type 'struct object_id'
2018-10-30Merge branch 'ch/subtree-build'Libravatar Junio C Hamano1-0/+4
Build update for "git subtree" (in contrib/) documentation pages. * ch/subtree-build: Revert "subtree: make install targets depend on build targets" subtree: make install targets depend on build targets subtree: add build targets 'man' and 'html'
2018-10-26Merge branch 'du/cherry-is-plumbing'Libravatar Junio C Hamano1-11/+0
Doc update to mark "git cherry" as a plumbing command. * du/cherry-is-plumbing: doc: move git-cherry to plumbing
2018-10-26Merge branch 'ds/coverage-diff'Libravatar Junio C Hamano1-0/+108
The result of coverage test can be combined with "git blame" to check the test coverage of code introduced recently with a new 'coverage-diff' tool (in contrib/). * ds/coverage-diff: contrib: add coverage-diff script
2018-10-26Merge branch 'rs/subtree-fixes'Libravatar Junio C Hamano1-46/+83
Various subtree fixes. * rs/subtree-fixes: subtree: performance improvement for finding unexpected parent commits subtree: improve decision on merges kept in split subtree: use commits before rejoins for splits subtree: make --ignore-joins pay attention to adds subtree: refactor split of a commit into standalone method
2018-10-25completion: support `git mergetool --[no-]gui`Libravatar Denton Liu1-1/+1
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Anmol Mago <anmolmago@gmail.com> Signed-off-by: Brian Ho <briankyho@gmail.com> Signed-off-by: David Lu <david.lu97@outlook.com> Signed-off-by: Ryan Wang <shirui.wang@hotmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24mingw: load system libraries the recommended wayLibravatar Johannes Schindelin1-1/+2
When we access IPv6-related functions, we load the corresponding system library using the `LoadLibrary()` function, which is not the recommended way to load system libraries. In practice, it does not make a difference: the `ws2_32.dll` library containing the IPv6 functions is already loaded into memory, so LoadLibrary() simply reuses the already-loaded library. Still, recommended way is recommended way, so let's use that instead. While at it, also adjust the code in contrib/ that loads system libraries. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24cocci: simplify "if (++u > 1)" to "if (u++)"Libravatar Junio C Hamano1-0/+5
It is more common to use post-increment than pre-increment when the side effect is the primary thing we want in our code and in C in general (unlike C++). Initializing a variable to 0, incrementing it every time we do something, and checking if we have already done that thing to guard the code to do that thing, is easier to understand when written if (u++) ; /* we've done that! */ else do_it(); /* just once. */ but if you try to use pre-increment, you end up with a less natural looking if (++u > 1) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-22completion: fix __gitcomp_builtin no longer consider extra optionsLibravatar Nguyễn Thái Ngọc Duy1-1/+1
__gitcomp_builtin() has the main completion list provided by git xxx --git-completion-helper but the caller can also add extra options that is not provided by --git-completion-helper. The only call site that does this is "git difftool" completion. This support is broken by b221b5ab9b (completion: collapse extra --no-.. options - 2018-06-06), which adds a special value "--" to mark that the rest of the options can be hidden by default. The commit forgets the fact that extra options are appended after "$(git xxx --git-completion-helper)", i.e. after this "--", and will be incorrectly hidden as well. Prepend the extra options before "$(git xxx --git-completion-helper)" to avoid this. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-19Merge branch 'nd/complete-fetch-multiple-args'Libravatar Junio C Hamano1-0/+1
Teach bash completion that "git fetch --multiple" only takes remote names as arguments and no refspecs. * nd/complete-fetch-multiple-args: completion: support "git fetch --multiple"
2018-10-18Revert "subtree: make install targets depend on build targets"Libravatar Junio C Hamano1-3/+3
This reverts commit 744f7c4c314dc0e7816ac05520e8358c8318187a. These targets do depend on the fact that each prereq is explicitly listed via their use of $^, which I failed to notice, and broke the build.