summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-09-21remote-mediawiki: fix duplicate revisions being importedSimon Legner1-0/+3
Fix a bug with revisions being imported twice. This commit is being backported from Git-Mediawiki.git's e41ee9b ("All revisions imported twice", 2018-02-02) to git.git. See [1] for the original commit and [2] and [3] for the upstream PR and issue. 1. https://github.com/Git-Mediawiki/Git-Mediawiki/commit/e41ee9b3a32416df381cdc79f63350665c84151e 2. https://github.com/Git-Mediawiki/Git-Mediawiki/pull/61 3. https://github.com/Git-Mediawiki/Git-Mediawiki/issues/29 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use CLI installerÆvar Arnfjörð Bjarmason6-334/+79
Replace the use of screen-scraping in the test environment installation with simply invoking MediaWiki's command-line installer. The old code being deleted here relied on our own hardcoded POST parameter names & the precise layout of MediaWiki's GUI installer at a given version. Somewhere between [1] and now this inevitably broke. As far as I can tell there was never a reason for this screen-scraping hack, when [1] was introduced it hardcoded MediaWiki 1.19.0, the CLI installer was introduced in 1.17.0. Perhaps the authors weren't aware of it, or this code was written for an older version. This allows us to simply delete our own template version of LocalSettings.php, it'll instead be provided by the CLI installer. While we're at it let's fix a few things, these changes weren't practical to split up (I'd need to fix code I was about to mostly delete) * Use MediaWiki's own defaults where possible, e.g. before we'd name the database "wikidb.sqlite", now we'll simply use whatever name MediaWiki prefers (currently my_wiki.sqlite) by only supplying the directory name the SQLite file will be dropped into, not the full path. * Put all of our database & download assets into a new "mediawiki/" folder. This makes it easier to reason about as the current & template "backup" database the tests keep swapping around live next to each other. This'll also prevent future potential breakage as there isn't a single SQLite database. MediaWiki also creates a job queue database and a couple of cache databases. In practice it seems we got away with not resetting these when we reset the main database, but it's the sort of thing that could break in the future (reset, main store doesn't have the article, but the cache does). * The "delete" function now only deletes the MediaWiki installation & database, not the downloaded .tar.gz file. This makes us friendlier to a developer on a slow connection. 1. 5ef6ad1785 ("git-remote-mediawiki: scripts to install, delete and clear a MediaWiki", 2012-07-06) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use inline PerlIO for readabilityÆvar Arnfjörð Bjarmason1-4/+3
Replace the use of the "open" pragma with a three-arg open in the places that actually care about UTF-8, while leaving those that don't (the config parsing). Unlike the previous "encoding" pragma change this isn't needed for compatibility with anything. I just think it's easier to read code that has localized effects than code that changes global settings. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: replace deprecated Perl constructÆvar Arnfjörð Bjarmason1-2/+1
The use of the encoding pragma has been a hard error since Perl 5.18 (released in 2013). What this script really wanted to do was to decode @ARGV and write out some files with the UTF-8 PerlIO layer. Let's just do that explicitly instead. This explicitly does not retain the previous UTF-8 semantics of the script. The "encoding" pragma had all sorts of global effects (program text being UTF-8, stdin/stdout etc.). But the only thing that was required was decoding @ARGV and writing out UTF-8 data, which is currently facilitated with the "open" pragma. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use a more idiomatic dispatch tableÆvar Arnfjörð Bjarmason1-7/+7
Change the dispatch table code in test-gitmw.pl to use a hash where subroutine references are the values. This is more obvious than a hash where the values are strings we'll use to go searching around in the symbol table for the function. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use "$dir/" instead of "$dir."Ævar Arnfjörð Bjarmason1-3/+3
Change UI messages to use "$dir/" instead of "$dir.". I think this is less confusing when referring to an absolute directory path. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: change `[]` to `test`Ævar Arnfjörð Bjarmason1-6/+11
Convert `[]` to `test` and break if-then into separate lines, both of which bring the style in line with Git's coding guidelines. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use test_cmp in testsÆvar Arnfjörð Bjarmason1-4/+4
Change code that used an ad-hoc "diff -b" invocation to use our test_cmp helper instead. I'm also changing the order of arguments to be the standard "test_cmp <expected> <actual>". Using test_cmp has different semantics since the "-b" option to diff causes it to ignore whitespace, but in these cases the use of "-b" was just meaningless boilerplate. The desired semantics here are to compare "git log" lines with know-good data, so we don't want to ignore whitespace. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use a 10 character passwordÆvar Arnfjörð Bjarmason1-1/+1
In more recent versions of MediaWiki this is a requirement, e.g. the current stable version of 1.32.2. The web installer now refuses our old 9 character password, the command-line one (will be used in a subsequent change) will accept it, but trying to use it in the web UI will emit an error asking the user to reset the password. Let's use a password that'll just work and allow us to log in as the admin user. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use the login/password variablesÆvar Arnfjörð Bjarmason1-2/+2
Change a hardcoded user/password for the corresponding variable defined in contrib/mw-to-git/t/test.config. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki doc: don't hardcode Debian PHP versionsÆvar Arnfjörð Bjarmason1-5/+5
Change the hardcoded version 5 PHP versions to the version-agnostic packages. Currently Debian stable's version is 7.3, and there's a php7.3, php7.3-cli etc. package available (but no php5-*). The corresponding version-less package is a dependency package which depends on whatever the current stable version is. By not hardcoding the version these instructions won't be out of date when the next Debian/Ubuntu release happens. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-20builtin/diff-index: learn --merge-baseDenton Liu7-6/+92
There is currently no easy way to take the diff between the working tree or index and the merge base between an arbitrary commit and HEAD. Even diff's `...` notation doesn't allow this because it only works between commits. However, the ability to do this would be desirable to a user who would like to see all the changes they've made on a branch plus uncommitted changes without taking into account changes made in the upstream branch. Teach diff-index and diff (with one commit) the --merge-base option which allows a user to use the merge base of a commit and HEAD as the "before" side. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-20t4068: add --merge-base testsDenton Liu1-1/+10
In the future, we will be adding more --merge-base tests to this test script. To prepare for that, rename the script accordingly and update its description. Also, add two basic --merge-base tests that don't require any functionality to be implemented yet. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-20diff-lib: define diff_get_merge_base()Denton Liu2-0/+47
In a future commit, we will be using this function to implement --merge-base functionality in various diff commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-20diff-lib: accept option flags in run_diff_index()Denton Liu4-10/+13
In a future commit, we will teach run_diff_index() to accept more options via flag bits. For now, change `cached` into a flag in the `option` bitfield. The behaviour should remain exactly the same. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-20docs: explain how to deal with files that are always modifiedbrian m. carlson1-0/+33
Users frequently have problems where two filenames differ only in case, causing one of those files to show up consistently as being modified. Let's add a FAQ entry that explains how to deal with that. In addition, let's explain another common case where files are consistently modified, which is when files using a smudge or clean filter have not been run through that filter. Explain the way to fix this as well. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-20docs: explain why reverts are not always applied on mergebrian m. carlson1-0/+21
A common scenario is for a user to apply a change to one branch and cherry-pick it into another, then later revert it in the first branch. This results in the change being present when the two branches are merged, which is confusing to many users. We already have documentation for how this works in `git merge`, but it is clear from the frequency with which this is asked that it's hard to grasp. We also don't explain to users that they are better off doing a rebase in this case, which will do what they intended. Let's add an entry to the FAQ telling users what's happening and advising them to use rebase here. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-20docs: explain why squash merges are broken with long-running branchesbrian m. carlson1-0/+32
In many projects, squash merges are commonly used, primarily to keep a tidy history in the face of developers who do not use logically independent, bisectable commits. As common as this is, this tends to cause significant problems when squash merges are used to merge long-running branches due to the lack of any new merge bases. Even very experienced developers may make this mistake, so let's add a FAQ entry explaining why this is problematic and explaining that regular merge commits should be used to merge two long-running branches. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-19send-pack: run GPG after atomic push checkingHan Xin2-26/+51
The refs update commands can be sent to the server side in two different ways: GPG-signed or unsigned. We should run these two operations in the same "Finally, tell the other end!" code block, but they are seperated by the "Clear the status for each ref" code block. This will result in a slight performance loss, because the failed atomic push will still perform unnecessary preparations for shallow advertise and GPG-signed commands buffers, and user may have to be bothered by the (possible) GPG passphrase input when there is nothing to sign. Add a new test case to t5534 to ensure GPG will not be called when the GPG-signed atomic push fails. Signed-off-by: Han Xin <hanxin.hx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-19Makefile: use git-archive --add-fileRené Scharfe1-22/+19
Add untracked files for the dist target directly using git archive instead of calling tar cr to append them. This reduces the dependency on external tools and gives the untracked files the same access times and user information as tracked ones, integrating them seamlessly. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-19archive: add --add-fileRené Scharfe5-1/+150
Allow users to append non-tracked files. This simplifies the generation of source packages with a few extra files, e.g. containing version information. They get the same access times and user information as tracked files. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-19archive: read short blobs in archive.c::write_archive_entry()René Scharfe4-48/+34
Centralize reading of symlink destinations and the contents of regular files that are too small to be streamed. This reduces code duplication and allows future patches to add support for adding non-tracked files to archives. The backends are expected to stream blobs if buffer is NULL. object_file_to_archive() is only called from archive.c and thus no longer exported. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-19git-p4: use HEAD~$n to find parent commit for unshelveLuke Diamand2-2/+2
Found-by: Liu Xuhui (Jackson) <Xuhui.Liu@amd.com> Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-19git-p4 unshelve: adding a commit breaks git-p4 unshelveLuke Diamand1-2/+5
git-p4 unshelve uses HEAD^$n to find the parent commit, which fails if there is an additional commit. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-19pack-write: use hashwrite_be32() in write_idx_file()René Scharfe1-8/+4
Call hashwrite_be32() instead of open-coding it. This shortens the code a bit and makes it easier to read. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-18Fifteenth batchJunio C Hamano1-1/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-18Merge branch 'mt/config-fail-nongit-early'Junio C Hamano2-9/+16
Unlike "git config --local", "git config --worktree" did not fail early and cleanly when started outside a git repository. * mt/config-fail-nongit-early: config: complain about --worktree outside of a git repo
2020-09-18Merge branch 'jc/dist-tarball-tweak'Junio C Hamano1-4/+7
Allow maintainers to tweak $(TAR) invocations done while making distribution tarballs. * jc/dist-tarball-tweak: Makefile: allow extra tweaking of distribution tarball
2020-09-18Merge branch 'mf/submodule-summary-with-correct-repository'Junio C Hamano3-15/+15
"git diff/show" on a change that involves a submodule used to read the information on commits in the submodule from a wrong repository and gave a wrong information when the commit-graph is involved. * mf/submodule-summary-with-correct-repository: submodule: use submodule repository when preparing summary revision: use repository from rev_info when parsing commits
2020-09-18Merge branch 'jc/quote-path-cleanup'Junio C Hamano7-60/+94
"git status --short" quoted a path with SP in it when tracked, but not those that are untracked, ignored or unmerged. They are all shown quoted consistently. * jc/quote-path-cleanup: quote: turn 'nodq' parameter into a set of flags quote: rename misnamed sq_lookup[] to cq_lookup[] wt-status: consistently quote paths in "status --short" output quote_path: code clarification quote_path: optionally allow quoting a path with SP in it quote_path: give flags parameter to quote_path() quote_path: rename quote_path_relative() to quote_path()
2020-09-18Merge branch 'os/collect-changed-submodules-optim'Junio C Hamano1-1/+8
Optimization around submodule handling. * os/collect-changed-submodules-optim: submodule: suppress checking for file name and ref ambiguity for object ids
2020-09-18Merge branch 'es/wt-add-detach'Junio C Hamano3-1/+15
"git worktree add" learns that the "-d" is a synonym to "--detach" option to create a new worktree without being on a branch. * es/wt-add-detach: git-worktree.txt: discuss branch-based vs. throwaway worktrees worktree: teach `add` to recognize -d as shorthand for --detach git-checkout.txt: document -d short option for --detach
2020-09-18Merge branch 'jk/add-i-fixes'Junio C Hamano3-2/+10
"add -i/-p" fixes. * jk/add-i-fixes: add--interactive.perl: specify --no-color explicitly add-patch: fix inverted return code of repo_read_index()
2020-09-18Merge branch 'pw/add-p-leakfix'Junio C Hamano1-8/+16
Leakfix. * pw/add-p-leakfix: add -p: fix memory leak
2020-09-18Merge branch 'jc/add-i-use-builtin-experimental'Junio C Hamano1-3/+9
The "add -i/-p" machinery has been written in C but it is not used by default yet. It is made default to those who are participating in feature.experimental experiment. * jc/add-i-use-builtin-experimental: add -i: use the built-in version when feature.experimental is set
2020-09-18Merge branch 'al/t3200-back-on-a-branch'Junio C Hamano1-0/+1
Test fix. * al/t3200-back-on-a-branch: t3200: clean side effect of git checkout --orphan
2020-09-18Merge branch 'hn/refs-ref-log-only-bit'Junio C Hamano2-7/+7
A bit of API reshuffling to make sure stuff common to all backends are not defined only in files backend. * hn/refs-ref-log-only-bit: refs: move REF_LOG_ONLY to refs-internal.h
2020-09-18Merge branch 'ea/blame-use-oideq'Junio C Hamano1-2/+2
Code cleanup. * ea/blame-use-oideq: blame.c: replace instance of !oidcmp for oideq
2020-09-18Merge branch 'pb/clang-json-compilation-database'Junio C Hamano2-5/+56
Developer support. * pb/clang-json-compilation-database: Makefile: add support for generating JSON compilation database
2020-09-18Merge branch 'so/log-tree-diff-cleanup'Junio C Hamano1-16/+5
Code cleanup. * so/log-tree-diff-cleanup: log_tree_diff: get rid of extra check for NULL log_tree_diff: get rid of code duplication for first_parent_only
2020-09-18Merge branch 'rs/parallel-read-cache-fix'Junio C Hamano1-1/+1
A follow-up fix to a topic already in 'master'. * rs/parallel-read-cache-fix: read-cache: fix mem-pool allocation for multi-threaded index loading
2020-09-18Merge branch 'rs/refspec-leakfix'Junio C Hamano6-51/+47
Leakfix. * rs/refspec-leakfix: refspec: add and use refspec_appendf() push: release strbufs used for refspec formatting
2020-09-18Merge branch 'rs/misc-cleanups'Junio C Hamano3-16/+6
Misc cleanups. * rs/misc-cleanups: pack-bitmap-write: use hashwrite_be32() in write_hash_cache() midx: use hashwrite_u8() in write_midx_header() fast-import: use write_pack_header()
2020-09-18Doc: prefer more specific file nameAaron Lipman4-3/+3
Change filters.txt to ref-reachability-filters.txt in order to avoid squatting on a file name that might be useful for another purpose. Signed-off-by: Aaron Lipman <alipman88@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-18ref-filter: make internal reachable-filter API more preciseAaron Lipman2-18/+14
The internal reachable-filter API is a bit loose and imprecise; it also bleeds unnecessarily into the public header. Tighten the API by: * renaming do_merge_filter() to reach_filter() * separating parameters to explicitly identify what data is used by the function instead of passing an entire ref_filter_cbdata struct * renaming and moving internal constants from header to source file Signed-off-by: Aaron Lipman <alipman88@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-18commit-graph: introduce 'commitGraph.maxNewFilters'Taylor Blau4-2/+43
Introduce a configuration variable to specify a default value for the recently-introduce '--max-new-filters' option of 'git commit-graph write'. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-18builtin/commit-graph.c: introduce '--max-new-filters=<n>'Taylor Blau6-8/+112
Introduce a command-line flag to specify the maximum number of new Bloom filters that a 'git commit-graph write' is willing to compute from scratch. Prior to this patch, a commit-graph write with '--changed-paths' would compute Bloom filters for all selected commits which haven't already been computed (i.e., by a previous commit-graph write with '--split' such that a roll-up or replacement is performed). This behavior can cause prohibitively-long commit-graph writes for a variety of reasons: * There may be lots of filters whose diffs take a long time to generate (for example, they have close to the maximum number of changes, diffing itself takes a long time, etc). * Old-style commit-graphs (which encode filters with too many entries as not having been computed at all) cause us to waste time recomputing filters that appear to have not been computed only to discover that they are too-large. This can make the upper-bound of the time it takes for 'git commit-graph write --changed-paths' to be rather unpredictable. To make this command behave more predictably, introduce '--max-new-filters=<n>' to allow computing at most '<n>' Bloom filters from scratch. This lets "computing" already-known filters proceed quickly, while bounding the number of slow tasks that Git is willing to do. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17commit-graph: rename 'split_commit_graph_opts'Taylor Blau3-34/+34
In the subsequent commit, additional options will be added to the commit-graph API which have nothing to do with splitting. Rename the 'split_commit_graph_opts' structure to the more-generic 'commit_graph_opts' to encompass both. Likewise, rename the 'flags' member to instead be 'split_flags' to clarify that it only has to do with the behavior implied by '--split'. Suggested-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17bloom: encode out-of-bounds filters as non-emptyTaylor Blau6-9/+54
When a changed-path Bloom filter has either zero, or more than a certain number (commonly 512) of entries, the commit-graph machinery encodes it as "missing". More specifically, it sets the indices adjacent in the BIDX chunk as equal to each other to indicate a "length 0" filter; that is, that the filter occupies zero bytes on disk. This has heretofore been fine, since the commit-graph machinery has no need to care about these filters with too few or too many changed paths. Both cases act like no filter has been generated at all, and so there is no need to store them. In a subsequent commit, however, the commit-graph machinery will learn to only compute Bloom filters for some commits in the current commit-graph layer. This is a change from the current implementation which computes Bloom filters for all commits that are in the layer being written. Critically for this patch, only computing some of the Bloom filters means adding a third state for length 0 Bloom filters: zero entries, too many entries, or "hasn't been computed". It will be important for that future patch to distinguish between "not representable" (i.e., zero or too-many changed paths), and "hasn't been computed". In particular, we don't want to waste time recomputing filters that have already been computed. To that end, change how we store Bloom filters in the "computed but not representable" category: - Bloom filters with no entries are stored as a single byte with all bits low (i.e., all queries to that Bloom filter will return "definitely not") - Bloom filters with too many entries are stored as a single byte with all bits set high (i.e., all queries to that Bloom filter will return "maybe"). These rules are sufficient to not incur a behavior change by changing the on-disk representation of these two classes. Likewise, no specification changes are necessary for the commit-graph format, either: - Filters that were previously empty will be recomputed and stored according to the new rules, and - old clients reading filters generated by new clients will interpret the filters correctly and be none the wiser to how they were generated. Clients will invoke the Bloom machinery in more cases than before, but this can be addressed by returning a NULL filter when all bits are set high. This can be addressed in a future patch. Note that this does increase the size of on-disk commit-graphs, but far less than other proposals. In particular, this is generally more efficient than storing a bitmap for which commits haven't computed their Bloom filters. Storing a bitmap incurs a penalty of one bit per commit, whereas storing explicit filters as above incurs a penalty of one byte per too-large or empty commit. In practice, these boundary commits likely occupy a small proportion of the overall number of commits, and so the size penalty is likely smaller than storing a bitmap for all commits. See, for example, these relative proportions of such boundary commits (collected by SZEDER Gábor): | Percentage of | commit-graph | | | commits modifying | file size | | ├────────┬──────────────┼───────────────────┤ pct. | | 0 path | >= 512 paths | before | after | change | ┌────────────────┼────────┼──────────────┼─────────┼─────────┼───────────┤ | android-base | 13.20% | 0.13% | 37.468M | 37.534M | +0.1741 % | | cmssw | 0.15% | 0.23% | 17.118M | 17.119M | +0.0091 % | | cpython | 3.07% | 0.01% | 7.967M | 7.971M | +0.0423 % | | elasticsearch | 0.70% | 1.00% | 8.833M | 8.835M | +0.0128 % | | gcc | 0.00% | 0.08% | 16.073M | 16.074M | +0.0030 % | | gecko-dev | 0.14% | 0.64% | 59.868M | 59.874M | +0.0105 % | | git | 0.11% | 0.02% | 3.895M | 3.895M | +0.0020 % | | glibc | 0.02% | 0.10% | 3.555M | 3.555M | +0.0021 % | | go | 0.00% | 0.07% | 3.186M | 3.186M | +0.0018 % | | homebrew-cask | 0.40% | 0.02% | 7.035M | 7.035M | +0.0065 % | | homebrew-core | 0.01% | 0.01% | 11.611M | 11.611M | +0.0002 % | | jdk | 0.26% | 5.64% | 5.537M | 5.540M | +0.0590 % | | linux | 0.01% | 0.51% | 63.735M | 63.740M | +0.0073 % | | llvm-project | 0.12% | 0.03% | 25.515M | 25.516M | +0.0050 % | | rails | 0.10% | 0.10% | 6.252M | 6.252M | +0.0027 % | | rust | 0.07% | 0.17% | 9.364M | 9.364M | +0.0033 % | | tensorflow | 0.09% | 1.02% | 7.009M | 7.010M | +0.0158 % | | webkit | 0.05% | 0.31% | 17.405M | 17.406M | +0.0047 % | (where the above increase is determined by computing a non-split commit-graph before and after this patch). Given that these projects are all "large" by commit count, the storage cost by writing these filters explicitly is negligible. In the most extreme example, android-base (which has 494,848 commits at the time of writing) would have its commit-graph increase by a modest 68.4 KB. Finally, a test to exercise filters which contain too many changed path entries will be introduced in a subsequent patch. Suggested-by: SZEDER Gábor <szeder.dev@gmail.com> Suggested-by: Jakub Narębski <jnareb@gmail.com> Helped-by: Derrick Stolee <dstolee@microsoft.com> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17contrib/completion: complete options that take refs for format-patchDenton Liu1-0/+4
The completion for format-patch currently suggests --base=, --interdiff= and --range-diff= as options. However, with these `=` forms of the options, there is no space and we'd enter the `--*` case which means we don't call the __git_complete_revlist() at the end. Teach _git_format_patch() to complete refs in the case of --base=, --interdiff= and --range-diff=. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>