summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2018-11-13Merge branch 'nd/tree-walk-path-exclusion'Libravatar Junio C Hamano1-0/+17
Pathspec matching against a tree object were buggy when negative pathspec elements were involved, which has been fixed. * nd/tree-walk-path-exclusion: tree-walk.c: fix overoptimistic inclusion in :(exclude) matching
2018-11-13Merge branch 'jk/misc-unused-fixes'Libravatar Junio C Hamano2-0/+9
Assorted fixes for bugs found while auditing -Wunused-parameter warnings. * jk/misc-unused-fixes: approxidate: fix NULL dereference in date_time() pathspec: handle non-terminated strings with :(attr) approxidate: handle pending number for "specials" rev-list: handle flags for --indexed-objects
2018-11-13Merge branch 'nd/per-worktree-ref-iteration'Libravatar Junio C Hamano4-0/+131
The code to traverse objects for reachability, used to decide what objects are unreferenced and expendable, have been taught to also consider per-worktree refs of other worktrees as starting points to prevent data loss. * nd/per-worktree-ref-iteration: git-worktree.txt: correct linkgit command name reflog expire: cover reflog from all worktrees fsck: check HEAD and reflog from other worktrees fsck: move fsck_head_link() to get_default_heads() to avoid some globals revision.c: better error reporting on ref from different worktrees revision.c: correct a parameter name refs: new ref types to make per-worktree refs visible to all worktrees Add a place for (not) sharing stuff between worktrees refs.c: indent with tabs, not spaces
2018-11-13Merge branch 'al/send-email-auto-cte-fixup'Libravatar Junio C Hamano1-0/+15
"git send-email --transfer-encoding=..." in recent versions of Git sometimes produced an empty "Content-Transfer-Encoding:" header, which has been corrected. * al/send-email-auto-cte-fixup: send-email: avoid empty transfer encoding header
2018-11-13Merge branch 'ds/add-missing-tags'Libravatar Junio C Hamano2-4/+82
The history traversal used to implement the tag-following has been optimized by introducing a new helper. * ds/add-missing-tags: remote: make add_missing_tags() linear test-reach: test get_reachable_subset commit-reach: implement get_reachable_subset
2018-11-13Merge branch 'js/rebase-p-tests'Libravatar Junio C Hamano14-43/+78
In preparation to the day when we can deprecate and remove the "rebase -p", make sure we can skip and later remove tests for it. * js/rebase-p-tests: tests: optionally skip `git rebase -p` tests t3418: decouple test cases from a previous `rebase -p` test case t3404: decouple some test cases from outcomes of previous test cases
2018-11-13Merge branch 'ag/rev-parse-all-exclude-fix'Libravatar Junio C Hamano1-0/+12
"git rev-parse --exclude=* --branches --branches" (i.e. first saying "add only things that do not match '*' out of all branches" and then adding all branches, without any exclusion this time") worked as expected, but "--exclude=* --all --all" did not work the same way, which has been fixed. * ag/rev-parse-all-exclude-fix: rev-parse: clear --exclude list after 'git rev-parse --all'
2018-11-13Merge branch 'jt/tighten-fetch-proto-v2-response'Libravatar Junio C Hamano1-0/+50
"git fetch" was a bit loose in parsing resposes from the other side when talking over the protocol v2. * jt/tighten-fetch-proto-v2-response: fetch-pack: be more precise in parsing v2 response
2018-11-13Merge branch 'ao/submodule-wo-gitmodules-checked-out'Libravatar Junio C Hamano7-16/+298
The submodule support has been updated to read from the blob at HEAD:.gitmodules when the .gitmodules file is missing from the working tree. * ao/submodule-wo-gitmodules-checked-out: t/helper: add test-submodule-nested-repo-config submodule: support reading .gitmodules when it's not in the working tree submodule: add a helper to check if it is safe to write to .gitmodules t7506: clean up .gitmodules properly before setting up new scenario submodule: use the 'submodule--helper config' command submodule--helper: add a new 'config' subcommand t7411: be nicer to future tests and really clean things up t7411: merge tests 5 and 6 submodule: factor out a config_set_in_gitmodules_file_gently function submodule: add a print_config_from_gitmodules() helper
2018-11-13Merge branch 'js/mingw-utf8-env'Libravatar Junio C Hamano1-1/+1
Windows fix. * js/mingw-utf8-env: mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8) t7800: fix quoting
2018-11-13Merge branch 'js/mingw-perl5lib'Libravatar Junio C Hamano1-0/+30
Windows fix. * js/mingw-perl5lib: mingw: unset PERL5LIB by default config: move Windows-specific config settings into compat/mingw.c config: allow for platform-specific core.* config settings config: rename `dummy` parameter to `cb` in git_default_config()
2018-11-13Merge branch 'ab/pack-tests-cleanup'Libravatar Junio C Hamano2-23/+28
A couple of tests used to leave the repository in a state that is deliberately corrupt, which have been corrected. * ab/pack-tests-cleanup: index-pack tests: don't leave test repo dirty at end pack-objects tests: don't leave test .git corrupt at end pack-objects test: modernize style
2018-11-13Merge branch 'ds/test-multi-pack-index'Libravatar Junio C Hamano4-2/+7
Tests for the recently introduced multi-pack index machinery. * ds/test-multi-pack-index: packfile: close multi-pack-index in close_all_packs multi-pack-index: define GIT_TEST_MULTI_PACK_INDEX midx: close multi-pack-index on repack midx: fix broken free() in close_midx()
2018-11-13Merge branch 'nd/wildmatch-double-asterisk'Libravatar Junio C Hamano1-2/+2
A pattern with '**' that does not have a slash on either side used to be an invalid one, but the code now treats such double-asterisks the same way as two normal asterisks that happen to be adjacent to each other. * nd/wildmatch-double-asterisk: wildmatch: change behavior of "foo**bar" in WM_PATHNAME mode
2018-11-13Merge branch 'nd/per-worktree-config'Libravatar Junio C Hamano3-60/+121
A fourth class of configuration files (in addition to the traditional "system wide", "per user in the $HOME directory" and "per repository in the $GIT_DIR/config") has been introduced so that different worktrees that share the same repository (hence the same $GIT_DIR/config file) can use different customization. * nd/per-worktree-config: worktree: add per-worktree config files t1300: extract and use test_cmp_config()
2018-11-13Merge branch 'jk/proto-v2-ref-prefix-fix'Libravatar Junio C Hamano1-0/+18
"git ls-remote $there foo" was broken by recent update for the protocol v2 and stopped showing refs that match 'foo' that are not refs/{heads,tags}/foo, which has been fixed. * jk/proto-v2-ref-prefix-fix: ls-remote: pass heads/tags prefixes to transport ls-remote: do not send ref prefixes for patterns
2018-11-13Merge branch 'jk/detect-truncated-zlib-input'Libravatar Junio C Hamano1-2/+21
A regression in Git 2.12 era made "git fsck" fall into an infinite loop while processing truncated loose objects. * jk/detect-truncated-zlib-input: cat-file: handle streaming failures consistently check_stream_sha1(): handle input underflow t1450: check large blob in trailing-garbage test
2018-11-07approxidate: fix NULL dereference in date_time()Libravatar Jeff King1-0/+1
When we see a time like "noon", we pass "12" to our date_time() helper, which sets the hour to 12pm. If the current time is before noon, then we wrap around to yesterday using date_yesterday(). But unlike the normal calls to date_yesterday() from approxidate_alpha(), we pass a NULL "num" parameter. Since c27cc94fad (approxidate: handle pending number for "specials", 2018-11-02), that causes a segfault. One way to fix this is by checking for NULL. But arguably date_time() is abusing our helper by passing NULL in the first place (and this is the only case where one of these "special" parsers is used this way). So instead, let's have it just do the 1-day subtraction itself. It's still just a one-liner due to our update_tm() helper. Note that the test added here is a little funny, as we say "10am noon", which makes the "10am" seem pointless. But this bug can only be triggered when it the currently-parsed hour is before the special time. The latest special time is "tea" at 1700, but t0006 uses a hard-coded TEST_DATE_NOW of 1900. We could reset TEST_DATE_NOW, but that may lead to confusion in other tests. Just saying "10am noon" makes this test self-contained. Reported-by: Carlo Arenas <carenas@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-06Merge branch 'sg/test-verbose-log'Libravatar Junio C Hamano2-2/+3
Our test scripts can now take the '-V' option as a synonym for the '--verbose-log' option. * sg/test-verbose-log: test-lib: introduce the '-V' short option for '--verbose-log'
2018-11-06Merge branch 'sg/test-rebase-editor-fix'Libravatar Junio C Hamano2-7/+7
* sg/test-rebase-editor-fix: t3404-rebase-interactive: test abbreviated commands
2018-11-06Merge branch 'md/exclude-promisor-objects-fix'Libravatar Junio C Hamano2-0/+8
Operations on promisor objects make sense in the context of only a small subset of the commands that internally use the revisions machinery, but the "--exclude-promisor-objects" option were taken and led to nonsense results by commands like "log", to which it didn't make much sense. This has been corrected. * md/exclude-promisor-objects-fix: exclude-promisor-objects: declare when option is allowed Documentation/git-log.txt: do not show --exclude-promisor-objects
2018-11-06Merge branch 'jt/upload-pack-v2-fix-shallow'Libravatar Junio C Hamano1-0/+25
"git fetch" over protocol v2 into a shallow repository failed to fetch full history behind a new tip of history that was diverged before the cut-off point of the history that was previously fetched shallowly. * jt/upload-pack-v2-fix-shallow: upload-pack: clear flags before each v2 request upload-pack: make want_obj not global upload-pack: make have_obj not global
2018-11-06Merge branch 'sb/submodule-url-to-absolute'Libravatar Junio C Hamano1-0/+24
Some codepaths failed to form a proper URL when .gitmodules record the URL to a submodule repository as relative to the repository of superproject, which has been corrected. * sb/submodule-url-to-absolute: submodule helper: convert relative URL to absolute URL if needed
2018-11-06Merge branch 'js/shallow-and-fetch-prune'Libravatar Junio C Hamano1-0/+27
"git repack" in a shallow clone did not correctly update the shallow points in the repository, leading to a repository that does not pass fsck. * js/shallow-and-fetch-prune: repack -ad: prune the list of shallow commits shallow: offer to prune only non-existing entries repack: point out a bug handling stale shallow info
2018-11-06Merge branch 'js/remote-archive-dwimfix'Libravatar Junio C Hamano2-1/+12
The logic to determine the archive type "git archive" uses did not correctly kick in for "git archive --remote", which has been corrected. * js/remote-archive-dwimfix: archive: initialize archivers earlier
2018-11-05tree-walk.c: fix overoptimistic inclusion in :(exclude) matchingLibravatar Nguyễn Thái Ngọc Duy1-0/+17
tree_entry_interesting() is used for matching pathspec on a tree. The interesting thing about this function is that, because the tree entries are known to be sorted, this function can return more than just "yes, matched" and "no, not matched". It can also say "yes, this entry is matched and so is the remaining entries in the tree". This is where I made a mistake when matching exclude pathspec. For exclude pathspec, we do matching twice, one with positive patterns and one with negative ones, then a rule table is applied to determine the final "include or exclude" result. Note that "matched" does not necessarily mean include. For negative patterns, "matched" means exclude. This particular rule is too eager to include everything. Rule 8 says that "if all entries are positively matched" and the current entry is not negatively matched (i.e. not excluded), then all entries are positively matched and therefore included. But this is not true. If the _current_ entry is not negatively matched, it does not mean the next one will not be and we cannot conclude right away that all remaining entries are positively matched and can be included. Rules 8 and 18 are now updated to be less eager. We conclude that the current entry is positively matched and included. But we say nothing about remaining entries. tree_entry_interesting() will be called again for those entries where we will determine entries individually. Reported-by: Christophe Bliard <christophe.bliard@trux.info> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-03Merge branch 'mg/gpg-fingerprint'Libravatar Junio C Hamano1-6/+12
New "--pretty=format:" placeholders %GF and %GP that show the GPG key fingerprints have been invented. * mg/gpg-fingerprint: gpg-interface.c: obtain primary key fingerprint as well gpg-interface.c: support getting key fingerprint via %GF format gpg-interface.c: use flags to determine key/signer info presence
2018-11-03Merge branch 'mg/gpg-parse-tighten'Libravatar Junio C Hamano1-0/+26
Detect and reject a signature block that has more than one GPG signature. * mg/gpg-parse-tighten: gpg-interface.c: detect and reject multiple signatures on commits
2018-11-03Merge branch 'en/merge-cleanup-more'Libravatar Junio C Hamano1-4/+4
Further clean-up of merge-recursive machinery. * en/merge-cleanup-more: merge-recursive: avoid showing conflicts with merge branch before HEAD merge-recursive: improve auto-merging messages with path collisions
2018-11-03test-reach: test get_reachable_subsetLibravatar Derrick Stolee2-4/+82
The get_reachable_subset() method returns the list of commits in the 'to' array that are reachable from at least one commit in the 'from' array. Add tests that check this method works in a few cases: 1. All commits in the 'to' list are reachable. This exercises the early-termination condition. 2. Some commits in the 'to' list are reachable. This exercises the loop-termination condition. 3. No commits in the 'to' list are reachable. This exercises the NULL return condition. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02send-email: avoid empty transfer encoding headerLibravatar Aaron Lindsay1-0/+15
Fix a small bug introduced by "7a36987ff (send-email: add an auto option for transfer encoding, 2018-07-14)". I saw the following message when setting --transfer-encoding for a file with the same encoding: $ git send-email --transfer-encoding=8bit example.patch Use of uninitialized value $xfer_encoding in concatenation (.) or string at /usr/lib/git-core/git-send-email line 1744. The new tests are by brian m. carlson. Signed-off-by: Aaron Lindsay <aaron@aclindsay.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02approxidate: handle pending number for "specials"Libravatar Jeff King1-0/+1
The approxidate parser has a table of special keywords like "yesterday", "noon", "pm", etc. Some of these, like "pm", do the right thing if we've recently seen a number: "3pm" is what you'd think. However, most of them do not look at or modify the pending-number flag at all, which means a number may "jump" across a significant keyword and be used unexpectedly. For example, when parsing: January 5th noon pm we'd connect the "5" to "pm", and ignore it as a day-of-month. This is obviously a bit silly, as "noon" already implies "pm". And other mis-parsed things are generally as silly ("January 5th noon, years ago" would connect the 5 to "years", but probably nobody would type that). However, the fix is simple: when we see a keyword like "noon", we should flush the pending number (as we would if we hit another number, or the end of the string). In a few of the specials that actually modify the day, we can simply throw away the number (saying "Jan 5 yesterday" should not respect the number at all). Note that we have to either move or forward-declare the static pending_number() to make it accessible to these functions; this patch moves it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02rev-list: handle flags for --indexed-objectsLibravatar Jeff King1-0/+7
When a traversal sees the --indexed-objects option, it adds all blobs and valid cache-trees from the index to the traversal using add_index_objects_to_pending(). But that function totally ignores its flags parameter! That means that doing: git rev-list --objects --indexed-objects and git rev-list --objects --not --indexed-objects produce the same output, because we ignore the UNINTERESTING flag when walking the index in the second example. Nobody noticed because this feature was added as a way for tools like repack to increase their coverage of reachable objects, meaning it would only be used like the first example above. But since it's user facing (and because the documentation describes it "as if the objects are listed on the command line"), we should make sure the negative case behaves sensibly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02tests: optionally skip `git rebase -p` testsLibravatar Johannes Schindelin14-36/+69
The `--preserve-merges` mode of the `rebase` command is slated to be deprecated soon, as the more powerful `--rebase-merges` mode is available now, and the latter was designed with the express intent to address the shortcomings of `--preserve-merges`' design (e.g. the inability to reorder commits in an interactive rebase). As such, we will eventually even remove the `--preserve-merges` support, and along with it, its tests. In preparation for this, and also to allow the Windows phase of our automated tests to save some well-needed time when running the test suite, this commit introduces a new prerequisite REBASE_P, which can be forced to being unmet by setting the environment variable `GIT_TEST_SKIP_REBASE_P` to any non-empty string. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02t3418: decouple test cases from a previous `rebase -p` test caseLibravatar Johannes Schindelin1-0/+1
It is in general a good idea for regression test cases to be as independent of each other as possible (with the one exception of an initial `setup` test case, which is only a test case in Git's test suite because it does not have a notion of a fixture or setup). This patch addresses one particular instance of this principle being violated: a few test cases in t3418-rebase-continue.sh depend on a side effect of a test case that verifies a specific `rebase -p` behavior. The later test cases should, however, still succeed even if the `rebase -p` test case is skipped. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02t3404: decouple some test cases from outcomes of previous test casesLibravatar Johannes Schindelin1-7/+8
Originally, the `--preserve-merges` option of the `git rebase` command piggy-backed on top of the `--interactive` feature. For that reason, the early test cases were added to the very same test script that contains the `git rebase -i` tests: `t3404-rebase-interactive.sh`. However, since c42abfe7857 (rebase: introduce a dedicated backend for --preserve-merges, 2018-05-28), the `--preserve-merges` feature got its own backend, in preparation for converting the rest of the `--interactive` code to built-in code, written in C rather than shell. The reason why the `--preserve-merges` feature was not converted at the same time is that we have something much better now: `--rebase-merges`. That option intends to supersede `--preserve-merges`, and we will probably deprecate the latter soon. Once `--preserve-merges` has been deprecated for a good amount of time, it will be time to remove it, and along with it, its tests. In preparation for that, let's make the rest of the test cases in `t3404-rebase-interactive.sh` independent of the test cases dedicated to `--preserve-merges`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02Merge branch 'js/rebase-i-shortopt'Libravatar Junio C Hamano2-2/+4
"git rebase -i" learned to take 'b' as the short form of 'break' option in the todo list. * js/rebase-i-shortopt: rebase -i: recognize short commands without arguments
2018-11-02Merge branch 'js/rebase-i-break'Libravatar Junio C Hamano2-1/+10
"git rebase -i" learned a new insn, 'break', that the user can insert in the to-do list. Upon hitting it, the command returns control back to the user. * js/rebase-i-break: rebase -i: introduce the 'break' command rebase -i: clarify what happens on a failed `exec`
2018-11-02Merge branch 'js/rebase-autostash-fix'Libravatar Junio C Hamano1-0/+10
"git rebase" that has recently been rewritten in C had a few issues in its "--autstash" feature, which have been corrected. * js/rebase-autostash-fix: rebase --autostash: fix issue with dirty submodules rebase --autostash: demonstrate a problem with dirty submodules rebase (autostash): use an explicit OID to apply the stash rebase (autostash): store the full OID in <state-dir>/autostash rebase (autostash): avoid duplicate call to state_dir_path()
2018-11-02Merge branch 'ag/rebase-i-in-c'Libravatar Junio C Hamano1-0/+10
Rewrite of the remaining "rebase -i" machinery in C. * ag/rebase-i-in-c: rebase -i: move rebase--helper modes to rebase--interactive rebase -i: remove git-rebase--interactive.sh rebase--interactive2: rewrite the submodes of interactive rebase in C rebase -i: implement the main part of interactive rebase as a builtin rebase -i: rewrite init_basic_state() in C rebase -i: rewrite write_basic_state() in C rebase -i: rewrite the rest of init_revisions_and_shortrevisions() in C rebase -i: implement the logic to initialize $revisions in C rebase -i: remove unused modes and functions rebase -i: rewrite complete_action() in C t3404: todo list with commented-out commands only aborts sequencer: change the way skip_unnecessary_picks() returns its result sequencer: refactor append_todo_help() to write its message to a buffer rebase -i: rewrite checkout_onto() in C rebase -i: rewrite setup_reflog_action() in C sequencer: add a new function to silence a command, except if it fails rebase -i: rewrite the edit-todo functionality in C editor: add a function to launch the sequence editor rebase -i: rewrite append_todo_help() in C sequencer: make three functions and an enum from sequencer.c public
2018-11-01rev-parse: clear --exclude list after 'git rev-parse --all'Libravatar Andreas Gruenbacher1-0/+12
Commit [1] added the --exclude option to revision.c. The --all, --branches, --tags, --remotes, and --glob options clear the exclude list. Shortly therafter, commit [2] added the same to 'git rev-parse', but without clearing the exclude list for the --all option. [1] e7b432c52 ("revision: introduce --exclude=<glob> to tame wildcards", 2013-08-30) [2] 9dc01bf06 ("rev-parse: introduce --exclude=<glob> to tame wildcards", 2013-11-01) Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-01fetch-pack: be more precise in parsing v2 responseLibravatar Jonathan Tan1-0/+50
Each section in a protocol v2 response is followed by either a DELIM packet (indicating more sections to follow) or a FLUSH packet (indicating none to follow). But when parsing the "acknowledgments" section, do_fetch_pack_v2() is liberal in accepting both, but determines whether to continue reading or not based solely on the contents of the "acknowledgments" section, not on whether DELIM or FLUSH was read. There is no issue with a protocol-compliant server, but can result in confusing error messages when communicating with a server that serves unexpected additional sections. Consider a server that sends "new-section" after "acknowledgments": - client writes request - client reads the "acknowledgments" section which contains no "ready", then DELIM - since there was no "ready", client needs to continue negotiation, and writes request - client reads "new-section", and reports to the end user "expected 'acknowledgments', received 'new-section'" For the person debugging the involved Git implementation(s), the error message is confusing in that "new-section" was not received in response to the latest request, but to the first one. One solution is to always continue reading after DELIM, but in this case, we can do better. We know from the protocol that "ready" means at least the packfile section is coming (hence, DELIM) and that no "ready" means that no sections are to follow (hence, FLUSH). So teach process_acks() to enforce this. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31t/helper: add test-submodule-nested-repo-configLibravatar Antonio Ospite4-0/+66
Add a test tool to exercise config_from_gitmodules(), in particular for the case of nested submodules. Add also a test to document that reading the submoudles config of nested submodules does not work yet when the .gitmodules file is not in the working tree but it still in the index. This is because the git API does not always make it possible access the object store of an arbitrary repository (see get_oid() usage in config_from_gitmodules()). When this git limitation gets fixed the aforementioned use case will be supported too. Signed-off-by: Antonio Ospite <ao2@ao2.it> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31submodule: support reading .gitmodules when it's not in the working treeLibravatar Antonio Ospite3-1/+163
When the .gitmodules file is not available in the working tree, try using the content from the index and from the current branch. This covers the case when the file is part of the repository but for some reason it is not checked out, for example because of a sparse checkout. This makes it possible to use at least the 'git submodule' commands which *read* the gitmodules configuration file without fully populating the working tree. Writing to .gitmodules will still require that the file is checked out, so check for that before calling config_set_in_gitmodules_file_gently. Add a similar check also in git-submodule.sh::cmd_add() to anticipate the eventual failure of the "git submodule add" command when .gitmodules is not safely writeable; this prevents the command from leaving the repository in a spurious state (e.g. the submodule repository was cloned but .gitmodules was not updated because config_set_in_gitmodules_file_gently failed). Moreover, since config_from_gitmodules() now accesses the global object store, it is necessary to protect all code paths which call the function against concurrent access to the global object store. Currently this only happens in builtin/grep.c::grep_submodules(), so call grep_read_lock() before invoking code involving config_from_gitmodules(). Finally, add t7418-submodule-sparse-gitmodules.sh to verify that reading from .gitmodules succeeds and that writing to it fails when the file is not checked out. NOTE: there is one rare case where this new feature does not work properly yet: nested submodules without .gitmodules in their working tree. This has been documented with a warning and a test_expect_failure item in t7814, and in this case the current behavior is not altered: no config is read. Signed-off-by: Antonio Ospite <ao2@ao2.it> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31ls-remote: pass heads/tags prefixes to transportLibravatar Jeff King1-0/+9
Unlike its arbitrary text patterns, the --heads and --tags options to ls-remote are true prefixes. We can pass this information to the transport code. If the v2 protocol is in use, that will reduce the size of the ref advertisement. Note that the test added here succeeds both before and after the patch. This is an optimization, not a bug-fix; it's just making sure we didn't break anything. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31ls-remote: do not send ref prefixes for patternsLibravatar Jeff King1-0/+9
Since b4be74105f (ls-remote: pass ref prefixes when requesting a remote's refs, 2018-03-15), "ls-remote foo" will pass "refs/heads/foo", "refs/tags/foo", etc to the transport code in an attempt to let the other side reduce the size of its advertisement. Unfortunately this is not correct, as ls-remote patterns do not follow the usual ref lookup rules, and are in fact tail-matched. So we could find "refs/heads/foo" or "refs/heads/a/much/deeper/foo" or even "refs/another/hierarchy/foo". Since we can't pass a prefix and there's not yet a v2 extension for matching wildcards, we must disable this feature to keep the same behavior as v1. Reported-by: Jon Simons <jon@jonsimons.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31Adjust for 2.19.x seriesLibravatar Junio C Hamano1-2/+21
* jk/detect-truncated-zlib-input cat-file: handle streaming failures consistently check_stream_sha1(): handle input underflow t1450: check large blob in trailing-garbage test
2018-10-31check_stream_sha1(): handle input underflowLibravatar Jeff King1-0/+19
This commit fixes an infinite loop when fscking large truncated loose objects. The check_stream_sha1() function takes an mmap'd loose object buffer and streams 4k of output at a time, checking its sha1. The loop quits when we've output enough bytes (we know the size from the object header), or when zlib tells us anything except Z_OK or Z_BUF_ERROR. The latter is expected because zlib may run out of room in our 4k buffer, and that is how it tells us to process the output and loop again. But Z_BUF_ERROR also covers another case: one in which zlib cannot make forward progress because it needs more _input_. This should never happen in this loop, because though we're streaming the output, we have the entire deflated input available in the mmap'd buffer. But since we don't check this case, we'll just loop infinitely if we do see a truncated object, thinking that zlib is asking for more output space. It's tempting to fix this by checking stream->avail_in as part of the loop condition (and quitting if all of our bytes have been consumed). But that assumes that once zlib has consumed the input, there is nothing left to do. That's not necessarily the case: it may have read our input into its internal state, but still have bytes to output. Instead, let's continue on Z_BUF_ERROR only when we see the case we're expecting: the previous round filled our output buffer completely. If it didn't (and we still saw Z_BUF_ERROR), we know something is wrong and should break out of the loop. The bug comes from commit f6371f9210 (sha1_file: add read_loose_object() function, 2017-01-13), which reimplemented some of the existing loose object functions. So it's worth checking if this bug was inherited from any of those. The answers seems to be no. The two obvious candidates are both OK: 1. unpack_sha1_rest(); this doesn't need to loop on Z_BUF_ERROR at all, since it allocates the expected output buffer in advance (which we can't do since we're explicitly streaming here) 2. check_object_signature(); the streaming path relies on the istream interface, which uses read_istream_loose() for this case. That function uses a similar "is our output buffer full" check with Z_BUF_ERROR (which is where I stole it from for this patch!) Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31t1450: check large blob in trailing-garbage testLibravatar Jeff King1-2/+2
Commit cce044df7f (fsck: detect trailing garbage in all object types, 2017-01-13) added two tests of trailing garbage in a loose object file: one with a commit and one with a blob. The point of having two is that blobs would follow a different code path that streamed the contents, instead of loading it into a buffer as usual. At the time, merely being a blob was enough to trigger the streaming code path. But since 7ac4f3a007 (fsck: actually fsck blob data, 2018-05-02), we now only stream blobs that are actually large. So since then, the streaming code path is not tested at all for this case. We can restore the original intent of the test by tweaking core.bigFileThreshold to make our small blob seem large. There's no easy way to externally verify that we followed the streaming code path, but I did check before/after using a temporary debug statement. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31mingw: unset PERL5LIB by defaultLibravatar Johannes Schindelin1-0/+30
Git for Windows ships with its own Perl interpreter, and insists on using it, so it will most likely wreak havoc if PERL5LIB is set before launching Git. Let's just unset that environment variables when spawning processes. To make this feature extensible (and overrideable), there is a new config setting `core.unsetenvvars` that allows specifying a comma-separated list of names to unset before spawning processes. Reported by Gabriel Fuhrmann. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>