summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-04Merge branch 'al/ref-filter-merged-and-no-merged'Libravatar Junio C Hamano1-1/+3
Hotfix. * al/ref-filter-merged-and-no-merged: ref-filter: plug memory leak in reach_filter()
2020-10-04Merge branch 'eg/mailinfo-doc-scissors'Libravatar Junio C Hamano1-4/+3
The explanation of the "scissors line" has been clarified. * eg/mailinfo-doc-scissors: Doc: show example scissors line
2020-10-04Merge branch 'mr/bisect-in-c-2'Libravatar Junio C Hamano3-78/+274
Rewrite of the "git bisect" script in C continues. * mr/bisect-in-c-2: bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C bisect: call 'clear_commit_marks_all()' in 'bisect_next_all()' bisect--helper: reimplement `bisect_autostart` shell function in C bisect--helper: introduce new `write_in_file()` function bisect--helper: use '-res' in 'cmd_bisect__helper' return bisect--helper: BUG() in cmd_*() on invalid subcommand
2020-10-04Merge branch 'cc/bisect-start-fix'Libravatar Junio C Hamano2-7/+13
"git bisect start X Y", when X and Y are not valid committish object names, should take X and Y as pathspec, but didn't. * cc/bisect-start-fix: bisect: don't use invalid oid as rev when starting
2020-10-04Merge branch 'jc/blame-ignore-fix'Libravatar Junio C Hamano4-25/+81
"git blame --ignore-rev/--ignore-revs-file" failed to validate their input are valid revision, and failed to take into account that the user may want to give an annotated tag instead of a commit, which has been corrected. * jc/blame-ignore-fix: blame: validate and peel the object names on the ignore list t8013: minimum preparatory clean-up
2020-10-04Merge branch 'jk/drop-unaligned-loads'Libravatar Junio C Hamano3-29/+4
Compilation fix around type punning. * jk/drop-unaligned-loads: Revert "fast-export: use local array to store anonymized oid" bswap.h: drop unaligned loads
2020-10-04Merge branch 'js/no-builtins-on-disk-option'Libravatar Junio C Hamano2-27/+40
The installation procedure learned to optionally omit "git-foo" executable files for each 'foo' built-in subcommand, which are only required by old timers that still rely on the age old promise that prepending "git --exec-path" output to PATH early in their script will keep the "git-foo" calls they wrote working. The old attempt to remove these executables from the disk failed in the 1.6 era; it may be worth attempting again, but I think it is worth to keep this topic separate from such a policy change to help it graduate early. * js/no-builtins-on-disk-option: ci: stop linking built-ins to the dashed versions Optionally skip linking/copying the built-ins msvc: copy the correct `.pdb` files in the Makefile target `install`
2020-10-04Merge branch 'ab/mediawiki-fixes'Libravatar Junio C Hamano13-401/+169
Modernization and fixes to MediaWiki remote backend. * ab/mediawiki-fixes: remote-mediawiki: use "sh" to eliminate unquoted commands remote-mediawiki: annotate unquoted uses of run_git() remote-mediawiki: convert to quoted run_git() invocation remote-mediawiki: provide a list form of run_git() remote-mediawiki tests: annotate failing tests remote-mediawiki: fix duplicate revisions being imported remote-mediawiki tests: use CLI installer remote-mediawiki tests: use inline PerlIO for readability remote-mediawiki tests: replace deprecated Perl construct remote-mediawiki tests: use a more idiomatic dispatch table remote-mediawiki tests: use "$dir/" instead of "$dir." remote-mediawiki tests: change `[]` to `test` remote-mediawiki tests: use test_cmp in tests remote-mediawiki tests: use a 10 character password remote-mediawiki tests: use the login/password variables remote-mediawiki doc: don't hardcode Debian PHP versions remote-mediawiki doc: link to MediaWiki's current version remote-mediawiki doc: correct link to GitHub project
2020-09-29Eighteenth batchLibravatar Junio C Hamano1-0/+24
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-29Merge branch 'ah/pull'Libravatar Junio C Hamano2-3/+21
Earlier we taught "git pull" to warn when the user does not say the histories need to be merged, rebased or accepts only fast- forwarding, but the warning triggered for those who have set the pull.ff configuration variable. * ah/pull: pull: don't warn if pull.ff has been set
2020-09-29Merge branch 'tg/range-diff-same-file-fix'Libravatar Junio C Hamano2-13/+11
"git range-diff" showed incorrect diffstat, which has been corrected. * tg/range-diff-same-file-fix: diff: fix modified lines stats with --stat and --numstat
2020-09-29Merge branch 'jc/t1506-rev-parse-leaves-range-endpoint-unpeeled'Libravatar Junio C Hamano1-0/+18
Test update. * jc/t1506-rev-parse-leaves-range-endpoint-unpeeled: t1506: rev-parse A..B and A...B
2020-09-29Merge branch 'dl/zero-oid-in-hooks'Libravatar Junio C Hamano2-10/+10
Adjust sample hooks for hash algorithm other than SHA-1. * dl/zero-oid-in-hooks: hooks--update.sample: use hash-agnostic zero OID hooks--pre-push.sample: use hash-agnostic zero OID hooks--pre-push.sample: modernize script
2020-09-29Merge branch 'jk/make-protocol-v2-the-default'Libravatar Junio C Hamano3-11/+2
The transport protocol v2 has become the default again. * jk/make-protocol-v2-the-default: protocol: re-enable v2 protocol by default
2020-09-29Merge branch 'bc/clone-with-git-default-hash-fix'Libravatar Junio C Hamano4-4/+20
"git clone" that clones from SHA-1 repository, while GIT_DEFAULT_HASH set to use SHA-256 already, resulted in an unusable repository that half-claims to be SHA-256 repository with SHA-1 objects and refs. This has been corrected. * bc/clone-with-git-default-hash-fix: builtin/clone: avoid failure with GIT_DEFAULT_HASH
2020-09-29Merge branch 'tb/bloom-improvements'Libravatar Junio C Hamano22-123/+508
"git commit-graph write" learned to limit the number of bloom filters that are computed from scratch with the --max-new-filters option. * tb/bloom-improvements: commit-graph: introduce 'commitGraph.maxNewFilters' builtin/commit-graph.c: introduce '--max-new-filters=<n>' commit-graph: rename 'split_commit_graph_opts' bloom: encode out-of-bounds filters as non-empty bloom/diff: properly short-circuit on max_changes bloom: use provided 'struct bloom_filter_settings' bloom: split 'get_bloom_filter()' in two commit-graph.c: store maximum changed paths commit-graph: respect 'commitGraph.readChangedPaths' t/helper/test-read-graph.c: prepare repo settings commit-graph: pass a 'struct repository *' in more places t4216: use an '&&'-chain commit-graph: introduce 'get_bloom_filter_settings()'
2020-09-29Merge branch 'bc/faq-misc'Libravatar Junio C Hamano1-0/+86
More FAQ entries. * bc/faq-misc: docs: explain how to deal with files that are always modified docs: explain why reverts are not always applied on merge docs: explain why squash merges are broken with long-running branches
2020-09-28Doc: show example scissors lineLibravatar Evan Gates1-4/+3
The text tries to say the code accepts many variations that look remotely like scissors and perforation marks, but gives too little detail for users to decide what is and what is not taken as a scissors line for themselves. Instead of describing the heuristics more, just spell out what will always be accepted, namely "-- >8 --", as it would not help users to give them more choices and flexibility and be "creative" in their scissors line. Signed-off-by: Evan Gates <evan.gates@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-26ref-filter: plug memory leak in reach_filter()Libravatar René Scharfe1-1/+3
21bf933928 (ref-filter: allow merged and no-merged filters, 2020-09-15) added an early return to reach_filter(). Avoid leaking the memory of a then unused array by postponing its allocation until we know we need it. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25Seventeenth batchLibravatar Junio C Hamano1-0/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25Merge branch 'jk/diff-highlight-blank-match-fix'Libravatar Junio C Hamano1-1/+1
"diff-highlight" (in contrib/) had a logic to flush its output upon seeing a blank line but the way it detected a blank line was broken. * jk/diff-highlight-blank-match-fix: diff-highlight: correctly match blank lines for flush
2020-09-25Merge branch 'hx/push-atomic-with-cert'Libravatar Junio C Hamano2-26/+51
"git push" that wants to be atomic and wants to send push certificate learned not to prepare and sign the push certificate when it fails the local check (hence due to atomicity it is known that no certificate is needed). * hx/push-atomic-with-cert: send-pack: run GPG after atomic push checking
2020-09-25Merge branch 'rs/misc-cleanups'Libravatar Junio C Hamano1-8/+4
Code cleanup. * rs/misc-cleanups: pack-write: use hashwrite_be32() in write_idx_file()
2020-09-25Merge branch 'ld/p4-unshelve-fix'Libravatar Junio C Hamano2-2/+5
The "unshelve" subcommand of "git p4" used incorrectly used commit^N where it meant to say commit~N to name the Nth generation ancestor, which has been corrected. * ld/p4-unshelve-fix: git-p4: use HEAD~$n to find parent commit for unshelve git-p4 unshelve: adding a commit breaks git-p4 unshelve
2020-09-25Merge branch 'jx/proc-receive-hook'Libravatar Junio C Hamano48-100/+4325
"git receive-pack" that accepts requests by "git push" learned to outsource most of the ref updates to the new "proc-receive" hook. * jx/proc-receive-hook: doc: add documentation for the proc-receive hook transport: parse report options for tracking refs t5411: test updates of remote-tracking branches receive-pack: new config receive.procReceiveRefs doc: add document for capability report-status-v2 New capability "report-status-v2" for git-push receive-pack: feed report options to post-receive receive-pack: add new proc-receive hook t5411: add basic test cases for proc-receive hook transport: not report a non-head push as a branch
2020-09-25Merge branch 'ds/maintenance-part-1'Libravatar Junio C Hamano24-28/+568
A "git gc"'s big brother has been introduced to take care of more repository maintenance tasks, not limited to the object database cleaning. * ds/maintenance-part-1: maintenance: add trace2 regions for task execution maintenance: add auto condition for commit-graph task maintenance: use pointers to check --auto maintenance: create maintenance.<task>.enabled config maintenance: take a lock on the objects directory maintenance: add --task option maintenance: add commit-graph task maintenance: initialize task array maintenance: replace run_auto_gc() maintenance: add --quiet option maintenance: create basic maintenance runner
2020-09-25t1506: rev-parse A..B and A...BLibravatar Junio C Hamano1-0/+18
Because these constructs can be used to parse user input to be passed to rev-list --objects, e.g. range=$(git rev-parse v1.0..v2.0) && git rev-list --objects $range | git pack-objects --stdin the endpoints (v1.0 and v2.0 in the example) are shown without peeling them to underlying commits, even when they are annotated tags. Make sure it stays that way. While at it, ensure "rev-parse A...B" also keeps the endpoints A and B unpeeled, even though the negative side (i.e. the merge-base between A and B) has to become a commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25protocol: re-enable v2 protocol by defaultLibravatar Jeff King3-11/+2
Protocol v2 became the default in v2.26.0 via 684ceae32d (fetch: default to protocol version 2, 2019-12-23). More widespread use turned up a regression in negotiation. That was fixed in v2.27.0 via 4fa3f00abb (fetch-pack: in protocol v2, in_vain only after ACK, 2020-04-27), but we also reverted the default to v0 as a precuation in 11c7f2a30b (Revert "fetch: default to protocol version 2", 2020-04-22). In v2.28.0, we re-enabled it for experimental users with 3697caf4b9 (config: let feature.experimental imply protocol.version=2, 2020-05-20) and haven't heard any complaints. v2.28 has only been out for 2 months, but I'd generally expect people turning on feature.experimental to also stay pretty up-to-date. So we're not likely to collect much more data by waiting. In addition, we have no further reports from people running v2.26.0, and of course some people have been setting protocol.version manually for ages. Let's move forward with v2 as the default again. It's possible there are still lurking bugs, but we won't know until it gets more widespread use. And we can find and squash them just like any other bug at this point. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25bisect: don't use invalid oid as rev when startingLibravatar Christian Couder2-7/+13
In 06f5608c14 (bisect--helper: `bisect_start` shell function partially in C, 2019-01-02), we changed the following shell code: - rev=$(git rev-parse -q --verify "$arg^{commit}") || { - test $has_double_dash -eq 1 && - die "$(eval_gettext "'\$arg' does not appear to be a valid revision")" - break - } - revs="$revs $rev" into: + char *commit_id = xstrfmt("%s^{commit}", arg); + if (get_oid(commit_id, &oid) && has_double_dash) + die(_("'%s' does not appear to be a valid " + "revision"), arg); + + string_list_append(&revs, oid_to_hex(&oid)); + free(commit_id); In case of an invalid "arg" when "has_double_dash" is false, the old code would "break" out of the argument loop. In the new C code though, `oid_to_hex(&oid)` is unconditonally appended to "revs". This is wrong first because "oid" is junk as `get_oid(commit_id, &oid)` failed and second because it doesn't break out of the argument loop. Not breaking out of the argument loop means that "arg" is then not treated as a path restriction (which is wrong). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24pull: don't warn if pull.ff has been setLibravatar Alex Henrie2-3/+21
A user who understands enough to set pull.ff does not need additional instructions. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24blame: validate and peel the object names on the ignore listLibravatar Junio C Hamano4-13/+69
The command reads list of object names to place on the ignore list either from the command line or from a file, but they are not checked with their object type (those read from the file are not even checked for object existence). Extend the oidset_parse_file() API and allow it to take a callback that can be used to die (e.g. when an inappropriate input is read) or modify the object name read (e.g. when a tag pointing at a commit is read, and the caller wants a commit object name), and use it in the code that handles ignore list. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24t8013: minimum preparatory clean-upLibravatar Junio C Hamano1-11/+11
The closing sq for each test piece should be placed at the beginning of line. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24diff: fix modified lines stats with --stat and --numstatLibravatar Thomas Guyot-Sionnest2-13/+11
Only skip diffstats when both oids are valid and identical. This check was causing both false-positives (files included in diffstats with no actual changes (0 lines modified) and false-negatives (showing 0 lines modified in stats when files had actually changed). Also replaced same_contents with may_differ to avoid confusion. Signed-off-by: Thomas Guyot-Sionnest <tguyot@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24Revert "fast-export: use local array to store anonymized oid"Libravatar Jeff King1-4/+4
This reverts commit f39ad38410da554af54966bf74fa0402355852ac. That commit was trying to silence a type-punning warning on older versions of gcc. However, its analysis was all wrong. I didn't notice that we _were_ in fact type-punning because there are two versions of put_be32(): one that uses casts and unaligned loads, and another that uses bitshifts. I looked at the latter, but on my platform we were defaulting to the former. However, as of the previous commit, we'll always use the bitshift version. So we can drop this hackery to avoid the warning, making the code slightly cleaner. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24bswap.h: drop unaligned loadsLibravatar Jeff King2-25/+0
Our put_be32() routine and its variants (get_be32(), put_be64(), etc) has two implementations: on some platforms we cast memory in place and use nothl()/htonl(), which can cause unaligned memory access. And on others, we pick out the individual bytes using bitshifts. This introduces extra complexity, and sometimes causes compilers to generate warnings about type-punning. And it's not clear there's any performance advantage. This split goes back to 660231aa97 (block-sha1: support for architectures with memory alignment restrictions, 2009-08-12). The unaligned versions were part of the original block-sha1 code in d7c208a92e (Add new optimized C 'block-sha1' routines, 2009-08-05), which says it is: Based on the mozilla SHA1 routine, but doing the input data accesses a word at a time and with 'htonl()' instead of loading bytes and shifting. Back then, Linus provided timings versus the mozilla code which showed a 27% improvement: https://lore.kernel.org/git/alpine.LFD.2.01.0908051545000.3390@localhost.localdomain/ However, the unaligned loads were either not the useful part of that speedup, or perhaps compilers and processors have changed since then. Here are times for computing the sha1 of 4GB of random data, with and without -DNO_UNALIGNED_LOADS (and BLK_SHA1=1, of course). This is with gcc 10, -O2, and the processor is a Core i9-9880H. [stock] Benchmark #1: t/helper/test-tool sha1 <foo.rand Time (mean ± σ): 6.638 s ± 0.081 s [User: 6.269 s, System: 0.368 s] Range (min … max): 6.550 s … 6.841 s 10 runs [-DNO_UNALIGNED_LOADS] Benchmark #1: t/helper/test-tool sha1 <foo.rand Time (mean ± σ): 6.418 s ± 0.015 s [User: 6.058 s, System: 0.360 s] Range (min … max): 6.394 s … 6.447 s 10 runs And here's the same test run on an AMD A8-7600, using gcc 8. [stock] Benchmark #1: t/helper/test-tool sha1 <foo.rand Time (mean ± σ): 11.721 s ± 0.113 s [User: 10.761 s, System: 0.951 s] Range (min … max): 11.509 s … 11.861 s 10 runs [-DNO_UNALIGNED_LOADS] Benchmark #1: t/helper/test-tool sha1 <foo.rand Time (mean ± σ): 11.744 s ± 0.066 s [User: 10.807 s, System: 0.928 s] Range (min … max): 11.637 s … 11.863 s 10 runs So the unaligned loads don't seem to help much, and actually make things worse. It's possible there are platforms where they provide more benefit, but: - the non-x86 platforms for which we use this code are old and obscure (powerpc and s390). - the main caller that cares about performance is block-sha1. But these days it is rarely used anyway, in favor of sha1dc (which is already much slower, and nobody seems to have cared that much). Let's just drop unaligned versions entirely in the name of simplicity. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell ↵Libravatar Pranit Bauva3-47/+191
functions in C Reimplement the `bisect_next()` and the `bisect_auto_next()` shell functions in C and add the subcommands to `git bisect--helper` to call them from git-bisect.sh . bisect_auto_next() function returns an enum bisect_error type as whole `git bisect` can exit with an error code when bisect_next() does. Return an error when `bisect_next()` fails, that fix a bug on shell script version. Using `--bisect-next` and `--bisect-auto-next` subcommands is a temporary measure to port shell function to C so as to use the existing test suite. As more functions are ported, `--bisect-auto-next` subcommand will be retired and will be called by some other methods. Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com> Signed-off-by: Miriam Rubio <mirucam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24bisect: call 'clear_commit_marks_all()' in 'bisect_next_all()'Libravatar Miriam Rubio1-0/+2
As there can be other revision walks after bisect_next_all(), let's add a call to a function to clear all the marks at the end of bisect_next_all(). Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Miriam Rubio <mirucam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24bisect--helper: reimplement `bisect_autostart` shell function in CLibravatar Pranit Bauva2-24/+45
Reimplement the `bisect_autostart()` shell function in C and add the C implementation from `bisect_next()` which was previously left uncovered. Add `--bisect-autostart` subcommand to be called from git-bisect.sh. Using `--bisect-autostart` subcommand is a temporary measure to port the shell function to C so as to use the existing test suite. As more functions are ported, this subcommand will be retired and bisect_autostart() will be called directly by `bisect_state()`. Change behavior of shell script that returned success when user aborted the bisection. Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com> Signed-off-by: Miriam Rubio <mirucam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-23hooks--update.sample: use hash-agnostic zero OIDLibravatar Denton Liu1-1/+1
The update sample hook has the zero OID hardcoded as 40 zeros. However, with the introduction of SHA-256 support, this assumption no longer holds true. Replace the hardcoded $z40 with a call to git hash-object --stdin </dev/null | tr '[0-9a-f]' '0' so the sample hook becomes hash-agnostic. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-23hooks--pre-push.sample: use hash-agnostic zero OIDLibravatar Denton Liu1-3/+3
The pre-push sample hook has the zero OID hardcoded as 40 zeros. However, with the introduction of SHA-256 support, this assumption no longer holds true. Replace the hardcoded $z40 with a call to git hash-object --stdin </dev/null | tr '[0-9a-f]' '0' so the sample hook becomes hash-agnostic. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-23hooks--pre-push.sample: modernize scriptLibravatar Denton Liu1-8/+8
The preferred form for a command substitution is $() over ``. Use this form for the command substitution in the sample hook. The preferred form for conditional tests is to use `test` over []. Replace [] with `test`. Finally, replace all instances of "sha" with "oid". Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-22Sixteenth batchLibravatar Junio C Hamano1-0/+31
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-22Merge branch 'ar/fetch-ipversion-in-all'Libravatar Junio C Hamano1-1/+4
"git fetch --all --ipv4/--ipv6" forgot to pass the protocol options to instances of the "git fetch" that talk to individual remotes, which has been corrected. * ar/fetch-ipversion-in-all: fetch: pass --ipv4 and --ipv6 options to sub-fetches
2020-09-22Merge branch 'dl/complete-format-patch-recent-features'Libravatar Junio C Hamano1-0/+4
Update to command line completion (in contrib/) * dl/complete-format-patch-recent-features: contrib/completion: complete options that take refs for format-patch
2020-09-22Merge branch 'cs/don-t-pretend-a-failed-remote-set-head-succeeded'Libravatar Junio C Hamano1-1/+1
"git remote set-head" that failed still said something that hints the operation went through, which was misleading. * cs/don-t-pretend-a-failed-remote-set-head-succeeded: remote: don't show success message when set-head fails
2020-09-22Merge branch 'jk/dont-count-existing-objects-twice'Libravatar Junio C Hamano2-0/+5
There is a logic to estimate how many objects are in the repository, which is mean to run once per process invocation, but it ran every time the estimated value was requested. * jk/dont-count-existing-objects-twice: packfile: actually set approximate_object_count_valid
2020-09-22Merge branch 'al/ref-filter-merged-and-no-merged'Libravatar Junio C Hamano13-77/+140
"git for-each-ref" and friends that list refs used to allow only one --merged or --no-merged to filter them; they learned to take combination of both kind of filtering. * al/ref-filter-merged-and-no-merged: Doc: prefer more specific file name ref-filter: make internal reachable-filter API more precise ref-filter: allow merged and no-merged filters Doc: cover multiple contains/no-contains filters t3201: test multiple branch filter combinations
2020-09-22Merge branch 'cd/commit-graph-doc'Libravatar Junio C Hamano1-1/+1
Doc update. * cd/commit-graph-doc: commit-graph-format.txt: fix no-parent value
2020-09-22Merge branch 'kk/build-portability-fix'Libravatar Junio C Hamano2-34/+34
Portability tweak for some shell scripts used while building. * kk/build-portability-fix: Fit to Plan 9's ANSI/POSIX compatibility layer
2020-09-22Merge branch 'ls/mergetool-meld-auto-merge'Libravatar Junio C Hamano3-16/+96
The 'meld' backend of the "git mergetool" learned to give the underlying 'meld' the '--auto-merge' option, which would help reduce the amount of text that requires manual merging. * ls/mergetool-meld-auto-merge: mergetool: allow auto-merge for meld to follow the vim-diff behavior