summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2019-04-02completion: support switchLibravatar Nguyễn Thái Ngọc Duy1-1/+36
Completion support for --guess could be made better. If no --detach is given, we should only provide a list of refs/heads/* and dwim ones, not the entire ref space. But I still can't penetrate that __git_refs() function yet. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@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.
2018-10-16subtree: make install targets depend on build targetsLibravatar Christian Hesse1-3/+3
Now that we have build targets let the install targets depend on them. Also make the targets phony. Signed-off-by: Christian Hesse <mail@eworm.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-15object_id.cocci: match only expressions of type 'struct object_id'Libravatar SZEDER Gábor1-54/+63
Most of our semantic patches in 'contrib/coccinelle/object_id.cocci' turn calls of SHA1-specific functions into calls of their corresponding object_id counterparts, e.g. sha1_to_hex() to oid_to_hex(). These semantic patches look something like this: @@ expression E1; @@ - sha1_to_hex(E1.hash) + oid_to_hex(&E1) and match the access to the 'hash' field in any data type, not only in 'struct object_id', and, consquently, can produce wrong transformations. Case in point is the recent hash function transition patch "rerere: convert to use the_hash_algo" [1], which, among other things, renamed 'struct rerere_dir's 'sha1' field to 'hash', and then 'make coccicheck' started to suggest the following wrong transformations for 'rerere.c' [2]: - return sha1_to_hex(id->collection->hash); + return oid_to_hex(id->collection); and - DIR *dir = opendir(git_path("rr-cache/%s", sha1_to_hex(rr_dir->hash))); + DIR *dir = opendir(git_path("rr-cache/%s", oid_to_hex(rr_dir))); Avoid such wrong transformations by tightening semantic patches in 'object_id.cocci' to match only type of or pointers to 'struct object_id'. [1] https://public-inbox.org/git/20181008215701.779099-15-sandals@crustytoothpaste.net/ [2] https://travis-ci.org/git/git/jobs/440463476#L580 Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-12subtree: performance improvement for finding unexpected parent commitsLibravatar Roger Strain1-1/+1
After testing a previous patch at larger scale, a performance issue was detected when using git show to locate parent revisions, with a single run of the git show command taking 2 seconds or longer in a complex repo. When the command is required tens or hundreds of times in a run of the script, the additional wait time is unaccepatable. Replacing the command with git rev-parse resulted in significantly increased performance, with the command in question returning instantly. Signed-off-by: Roger Strain <rstrain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-12doc: move git-cherry to plumbingLibravatar Daniels Umanovskis1-11/+0
Also remove git-cherry from Bash completion because plumbing commands do not belong there. Signed-off-by: Daniels Umanovskis <daniels@umanovskis.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-10subtree: add build targets 'man' and 'html'Libravatar Christian Hesse1-0/+4
We have targets 'install-man' and 'install-html', let's add build targets as well. Signed-off-by: Christian Hesse <mail@eworm.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-10contrib: add coverage-diff scriptLibravatar Derrick Stolee1-0/+108
We have coverage targets in our Makefile for using gcov to display line coverage based on our test suite. The way I like to do it is to run: make coverage-test make coverage-report This leaves the repo in a state where every X.c file that was covered has an X.c.gcov file containing the coverage counts for every line, and "#####" at every uncovered line. There have been a few bugs in recent patches what would have been caught if the test suite covered those blocks (including a few of mine). I want to work towards a "sensible" amount of coverage on new topics. In my opinion, this means that any logic should be covered, but the 'die()' blocks covering very unlikely (or near-impossible) situations may not warrant coverage. It is important to not measure the coverage of the codebase by what old code is not covered. To help, I created the 'contrib/coverage-diff.sh' script. After creating the coverage statistics at a version (say, 'topic') you can then run contrib/coverage-diff.sh base topic to see the lines added between 'base' and 'topic' that are not covered by the test suite. The output uses 'git blame -s' format so you can find the commits responsible and view the line numbers for quick access to the context, but trims leading tabs in the file contents to reduce output width. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>