summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-10-07Merge branch 'jt/merge-recursive-symlink-is-not-a-dir-in-way'Libravatar Junio C Hamano1-0/+28
A bug in merge-recursive code that triggers when a branch with a symbolic link is merged with a branch that replaces it with a directory has been fixed. * jt/merge-recursive-symlink-is-not-a-dir-in-way: merge-recursive: symlink's descendants not in way
2019-10-07Merge branch 'sg/t-helper-gitignore'Libravatar Junio C Hamano1-5/+4
Update the way build artifacts in t/helper/ directory are ignored. * sg/t-helper-gitignore: t/helper: ignore only executable files
2019-10-07Merge branch 'sg/progress-fix'Libravatar Junio C Hamano5-3/+372
Regression fix for progress output. * sg/progress-fix: Test the progress display Revert "progress: use term_clear_line()"
2019-10-07Merge branch 'tb/commit-graph-harden'Libravatar Junio C Hamano1-0/+43
The code to parse and use the commit-graph file has been made more robust against corrupted input. * tb/commit-graph-harden: commit-graph.c: handle corrupt/missing trees commit-graph.c: handle commit parsing errors t/t5318: introduce failing 'git commit-graph write' tests
2019-10-07Merge branch 'jt/cache-tree-avoid-lazy-fetch-during-merge'Libravatar Junio C Hamano1-0/+14
The cache-tree code has been taught to be less aggressive in attempting to see if a tree object it computed already exists in the repository. * jt/cache-tree-avoid-lazy-fetch-during-merge: cache-tree: do not lazy-fetch tentative tree
2019-10-07Merge branch 'gs/commit-graph-progress'Libravatar Junio C Hamano2-1/+37
* gs/commit-graph-progress: commit-graph: add --[no-]progress to write and verify
2019-10-07Merge branch 'rs/nth-parent-parse'Libravatar Junio C Hamano1-0/+8
The object name parser for "Nth parent" syntax has been made more robust against integer overflows. * rs/nth-parent-parse: sha1-name: check for overflow of N in "foo^N" and "foo~N" rev-parse: demonstrate overflow of N for "foo^N" and "foo~N"
2019-10-07Merge branch 'jk/disable-commit-graph-during-upload-pack'Libravatar Junio C Hamano1-0/+38
The "upload-pack" (the counterpart of "git fetch") needs to disable commit-graph when responding to a shallow clone/fetch request, but the way this was done made Git panic, which has been corrected. * jk/disable-commit-graph-during-upload-pack: upload-pack: disable commit graph more gently for shallow traversal commit-graph: bump DIE_ON_LOAD check to actual load-time
2019-10-07Merge branch 'ss/get-time-cleanup'Libravatar Junio C Hamano1-18/+9
Code simplification. * ss/get-time-cleanup: test_date.c: remove reference to GIT_TEST_DATE_NOW Quit passing 'now' to date code
2019-10-07Merge branch 'rs/simplify-by-deco-with-deco-refs-exclude'Libravatar Junio C Hamano1-0/+15
"git log --decorate-refs-exclude=<pattern>" was incorrectly overruled when the "--simplify-by-decoration" option is used, which has been corrected. * rs/simplify-by-deco-with-deco-refs-exclude: log-tree: call load_ref_decorations() in get_name_decoration() log: test --decorate-refs-exclude with --simplify-by-decoration
2019-10-07Merge branch 'jk/partial-clone-sparse-blob'Libravatar Junio C Hamano1-0/+36
The name of the blob object that stores the filter specification for sparse cloning/fetching was interpreted in a wrong place in the code, causing Git to abort. * jk/partial-clone-sparse-blob: list-objects-filter: use empty string instead of NULL for sparse "base" list-objects-filter: give a more specific error sparse parsing error list-objects-filter: delay parsing of sparse oid t5616: test cloning/fetching with sparse:oid=<oid> filter
2019-10-07Merge branch 'tg/stash-refresh-index'Libravatar Junio C Hamano1-0/+16
"git stash" learned to write refreshed index back to disk. * tg/stash-refresh-index: stash: make sure to write refreshed cache merge: use refresh_and_write_cache factor out refresh_and_write_cache function
2019-09-30Merge branch 'ds/commit-graph-on-fetch'Libravatar Junio C Hamano1-0/+13
A configuration variable tells "git fetch" to write the commit graph after finishing. * ds/commit-graph-on-fetch: fetch: add fetch.writeCommitGraph config setting
2019-09-30Merge branch 'bw/rebase-autostash-keep-current-branch'Libravatar Junio C Hamano1-4/+8
"git rebase --autostash <upstream> <branch>", when <branch> is different from the current branch, incorrectly moved the tip of the current branch, which has been corrected. * bw/rebase-autostash-keep-current-branch: builtin/rebase.c: Remove pointless message builtin/rebase.c: make sure the active branch isn't moved when autostashing
2019-09-30Merge branch 'jh/trace2-pretty-output'Libravatar Junio C Hamano1-2/+2
Output from trace2 subsystem is formatted more prettily now. * jh/trace2-pretty-output: trace2: cleanup whitespace in perf format trace2: cleanup whitespace in normal format quote: add sq_append_quote_argv_pretty() trace2: trim trailing whitespace in normal format error message trace2: remove dead code in maybe_add_string_va() trace2: trim whitespace in region messages in perf target format trace2: cleanup column alignment in perf target format
2019-09-30Merge branch 'dl/rebase-i-keep-base'Libravatar Junio C Hamano6-2/+270
"git rebase --keep-base <upstream>" tries to find the original base of the topic being rebased and rebase on top of that same base, which is useful when running the "git rebase -i" (and its limited variant "git rebase -x"). The command also has learned to fast-forward in more cases where it can instead of replaying to recreate identical commits. * dl/rebase-i-keep-base: rebase: teach rebase --keep-base rebase tests: test linear branch topology rebase: fast-forward --fork-point in more cases rebase: fast-forward --onto in more cases rebase: refactor can_fast_forward into goto tower t3432: test for --no-ff's interaction with fast-forward t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests t3432: test rebase fast-forward behavior t3431: add rebase --fork-point tests
2019-09-30Merge branch 'sg/clean-nested-repo-with-ignored'Libravatar Junio C Hamano1-0/+22
A bug documentation. * sg/clean-nested-repo-with-ignored: t7300-clean: demonstrate deleting nested repo with an ignored file breakage
2019-09-30Merge branch 'dl/complete-cherry-pick-revert-skip'Libravatar Junio C Hamano1-0/+6
The command line completion support (in contrib/) learned about the "--skip" option of "git revert" and "git cherry-pick". * dl/complete-cherry-pick-revert-skip: status: mention --skip for revert and cherry-pick completion: add --skip for cherry-pick and revert completion: merge options for cherry-pick and revert
2019-09-30Merge branch 'dl/use-sq-from-test-lib'Libravatar Junio C Hamano11-61/+51
Code cleanup. * dl/use-sq-from-test-lib: t: use common $SQ variable
2019-09-30Merge branch 'jk/misc-uninitialized-fixes'Libravatar Junio C Hamano1-3/+2
Various fixes to codepaths gcc 9 had trouble following dataflow. * jk/misc-uninitialized-fixes: pack-objects: drop packlist index_pos optimization test-read-cache: drop namelen variable diff-delta: set size out-parameter to 0 for NULL delta bulk-checkin: zero-initialize hashfile_checkpoint pack-objects: use object_id in packlist_alloc() git-am: handle missing "author" when parsing commit
2019-09-30Merge branch 'sg/git-test-boolean'Libravatar Junio C Hamano1-1/+1
Fix an earlier regression in the test suite, which mistakenly stopped running HTTPD tests. * sg/git-test-boolean: ci: restore running httpd tests t/lib-git-svn.sh: check GIT_TEST_SVN_HTTPD when running SVN HTTP tests
2019-09-30Merge branch 'en/filter-branch-deprecation'Libravatar Junio C Hamano2-9/+8
Start discouraging the use of "git filter-branch". * en/filter-branch-deprecation: t9902: use a non-deprecated command for testing Recommend git-filter-repo instead of git-filter-branch t6006: simplify, fix, and optimize empty message test
2019-09-30Merge branch 'tg/push-all-in-mirror-forbidden'Libravatar Junio C Hamano1-0/+10
Fix an earlier regression to "git push --all" which should have been forbidden when the target remote repository is set to be a mirror. * tg/push-all-in-mirror-forbidden: push: disallow --all and refspecs when remote.<name>.mirror is set
2019-09-30Merge branch 'tb/file-url-to-unc-path'Libravatar Junio C Hamano1-2/+11
Windows update. * tb/file-url-to-unc-path: mingw: support UNC in git clone file://server/share/repo
2019-09-30Merge branch 'dl/format-patch-doc-test-cleanup'Libravatar Junio C Hamano1-407/+407
The documentation and tests for "git format-patch" have been cleaned up. * dl/format-patch-doc-test-cleanup: config/format.txt: specify default value of format.coverLetter Doc: add more detail for git-format-patch t4014: stop losing return codes of git commands t4014: remove confusing pipe in check_threading() t4014: use test_line_count() where possible t4014: let sed open its own files t4014: drop redirections to /dev/null t4014: use indentable here-docs t4014: remove spaces after redirect operators t4014: use sq for test case names t4014: move closing sq onto its own line t4014: s/expected/expect/ t4014: drop unnecessary blank lines from test cases
2019-09-30Merge branch 'bc/hash-independent-tests-part-5'Libravatar Junio C Hamano14-328/+640
Preparation for SHA-256 upgrade continues in the test department. * bc/hash-independent-tests-part-5: t4009: make hash size independent t4002: make hash independent t4000: make hash size independent t3903: abstract away SHA-1-specific constants t3800: make hash-size independent t3600: make hash size independent t3506: make hash independent t3430: avoid hard-coded object IDs t3404: abstract away SHA-1-specific constants t3306: abstract away SHA-1-specific constants t3305: make hash size independent t3301: abstract away SHA-1-specific constants t3206: abstract away hash size constants t3201: abstract away SHA-1-specific constants
2019-09-30Merge branch 'jc/test-cleanup'Libravatar Junio C Hamano4-10/+0
Code cleanup. * jc/test-cleanup: t3005: remove unused variable t: use LF variable defined in the test harness
2019-09-20t/helper: ignore only executable filesLibravatar SZEDER Gábor1-5/+4
This patch conceptually reverts 44103f4197 (t/helper: ignore everything but sources, 2017-12-12). Back in those days we did have a lot of separate test helper executables under 't/helper', and its '.gitignore' did get out of sync every once in a while. Since then, however, most of those separate executables were integrated into a single 'test-tool' command [1], and new test helpers are added as new subcommands, so the chances of that '.gitignore' getting out of sync again are much lower. And even if a contributor were not careful enough and submits a patch that adds a new executable under 't/helper' but forgets to update '.gitignore' accordingly, our CI builds would catch it in a timely manner [2]. Ignoring everything but sources has the drawback that building an older version of Git (e.g. during bisecting) creates all those executables, and after going back to e.g. current 'master' the usual cleanup commands like 'make clean' or 'git clean -fd' don't remove them (the former doesn't know about them, and the latter doesn't remove ignored files). So let's ignore only the executable files under 't/helper/, i.e. 'test-tool' and the three other remaining executables that could not be integrated into 'test-tool' (no need to ignore object files, as they are already ignored by our toplevel '.gitignore'). [1] The topic starting with efd71f8913 (t/helper: add an empty test-tool program, 2018-03-24), and leading up to the merge commit 27f25845cf (Merge branch 'nd/combined-test-helper', 2018-04-11). [2] b92cb86ea1 (travis-ci: check that all build artifacts are .gitignore-d, 2017-12-31) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-20merge-recursive: symlink's descendants not in wayLibravatar Jonathan Tan1-0/+28
When the working tree has: - bar (directory) - bar/file (file) - foo (symlink to .) (note that lstat() for "foo/bar" would tell us that it is a directory) and the user merges a commit that deletes the foo symlink and instead contains: - bar (directory, as above) - bar/file (file, as above) - foo (directory) - foo/bar (file) the merge should happen without requiring user intervention. However, this does not happen. This is because dir_in_way(), when checking the working tree, thinks that "foo/bar" is a directory. But a symlink should be treated much the same as a file: since dir_in_way() is only checking to see if there is a directory in the way, we don't want symlinks in leading paths to sometimes cause dir_in_way() to return true. Teach dir_in_way() to also check for symlinks in leading paths before reporting whether a directory is in the way. Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-20stash: make sure to write refreshed cacheLibravatar Thomas Gummerer1-0/+16
When converting stash into C, calls to 'git update-index --refresh' were replaced with the 'refresh_cache()' function. That is fine as long as the index is only needed in-core, and not re-read from disk. However in many cases we do actually need the refreshed index to be written to disk, for example 'merge_recursive_generic()' discards the in-core index before re-reading it from disk, and in the case of 'apply --quiet', the 'refresh_cache()' we currently have is pointless without writing the index to disk. Always write the index after refreshing it to ensure there are no regressions in this compared to the scripted stash. In the future we can consider avoiding the write where possible after making sure none of the subsequent calls actually need the refreshed cache, and it is not expected to be refreshed after stash exits or it is written somewhere else already. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-18commit-graph: add --[no-]progress to write and verifyLibravatar Garima Singh2-1/+37
Add --[no-]progress to git commit-graph write and verify. The progress feature was introduced in 7b0f229 ("commit-graph write: add progress output", 2018-09-17) but the ability to opt-out was overlooked. Signed-off-by: Garima Singh <garima.singh@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-18test_date.c: remove reference to GIT_TEST_DATE_NOWLibravatar Stephen P. Smith1-1/+0
Remove the reference to the GIT_TEST_DATE_NOW which is done in date.c. We can't get rid of the "x" variable, since it serves as a generic scratch variable for parsing later in the function. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-18Merge branch 'jt/avoid-ls-refs-with-http'Libravatar Junio C Hamano2-0/+24
The http transport lacked some optimization the native transports learned to avoid unnecessary ref advertisement, which has been corrected. * jt/avoid-ls-refs-with-http: transport: teach all vtables to allow fetch first transport-helper: skip ls-refs if unnecessary
2019-09-18Merge branch 'md/list-objects-filter-combo'Libravatar Junio C Hamano2-8/+205
The list-objects-filter API (used to create a sparse/lazy clone) learned to take a combined filter specification. * md/list-objects-filter-combo: list-objects-filter-options: make parser void list-objects-filter-options: clean up use of ALLOC_GROW list-objects-filter-options: allow mult. --filter strbuf: give URL-encoding API a char predicate fn list-objects-filter-options: make filter_spec a string_list list-objects-filter-options: move error check up list-objects-filter: implement composite filters list-objects-filter-options: always supply *errbuf list-objects-filter: put omits set in filter struct list-objects-filter: encapsulate filter components
2019-09-18Merge branch 'cc/multi-promisor'Libravatar Junio C Hamano3-9/+59
Teach the lazy clone machinery that there can be more than one promisor remote and consult them in order when downloading missing objects on demand. * cc/multi-promisor: Move core_partial_clone_filter_default to promisor-remote.c Move repository_format_partial_clone to promisor-remote.c Remove fetch-object.{c,h} in favor of promisor-remote.{c,h} remote: add promisor and partial clone config to the doc partial-clone: add multiple remotes in the doc t0410: test fetching from many promisor remotes builtin/fetch: remove unique promisor remote limitation promisor-remote: parse remote.*.partialclonefilter Use promisor_remote_get_direct() and has_promisor_remote() promisor-remote: use repository_format_partial_clone promisor-remote: add promisor_remote_reinit() promisor-remote: implement promisor_remote_get_direct() Add initial support for many promisor remotes fetch-object: make functions return an error code t0410: remove pipes after git commands
2019-09-18Merge branch 'sg/line-log-tree-diff-optim'Libravatar Junio C Hamano1-0/+82
Optimize unnecessary full-tree diff away from "git log -L" machinery. * sg/line-log-tree-diff-optim: line-log: avoid unnecessary full tree diffs line-log: extract pathspec parsing from line ranges into a helper function
2019-09-18Merge branch 'sg/complete-configuration-variables'Libravatar Junio C Hamano1-0/+63
Command line completion updates for "git -c var.name=val" * sg/complete-configuration-variables: completion: complete config variables and values for 'git clone --config=' completion: complete config variables names and values for 'git clone -c' completion: complete values of configuration variables after 'git -c var=' completion: complete configuration sections and variable names for 'git -c' completion: split _git_config() completion: simplify inner 'case' pattern in __gitcomp() completion: use 'sort -u' to deduplicate config variable names completion: deduplicate configuration sections completion: add tests for 'git config' completion completion: complete more values of more 'color.*' configuration variables completion: fix a typo in a comment
2019-09-18Merge branch 'js/pre-merge-commit-hook'Libravatar Junio C Hamano2-139/+281
A new "pre-merge-commit" hook has been introduced. * js/pre-merge-commit-hook: merge: --no-verify to bypass pre-merge-commit hook git-merge: honor pre-merge-commit hook merge: do no-verify like commit t7503: verify proper hook execution
2019-09-18Merge branch 'js/rebase-r-strategy'Libravatar Junio C Hamano5-101/+113
"git rebase --rebase-merges" learned to drive different merge strategies and pass strategy specific options to them. * js/rebase-r-strategy: t3427: accelerate this test by using fast-export and fast-import rebase -r: do not (re-)generate root commits with `--root` *and* `--onto` t3418: test `rebase -r` with merge strategies t/lib-rebase: prepare for testing `git rebase --rebase-merges` rebase -r: support merge strategies other than `recursive` t3427: fix another incorrect assumption t3427: accommodate for the `rebase --merge` backend having been replaced t3427: fix erroneous assumption t3427: condense the unnecessarily repetitive test cases into three t3427: move the `filter-branch` invocation into the `setup` case t3427: simplify the `setup` test case significantly t3427: add a clarifying comment rebase: fold git-rebase--common into the -p backend sequencer: the `am` and `rebase--interactive` scripts are gone .gitignore: there is no longer a built-in `git-rebase--interactive` t3400: stop referring to the scripted rebase Drop unused git-rebase--am.sh
2019-09-17Test the progress displayLibravatar SZEDER Gábor4-0/+369
'progress.c' has seen a few fixes recently [1], and, unfortunately, some of those fixes required further fixes [2]. It seems it's time to have a few tests focusing on the subtleties of the progress display. Add the 'test-tool progress' subcommand to help testing the progress display, reading instructions from standard input and turning them into calls to the display_progress() and display_throughput() functions with the given parameters. The progress display is, however, critically dependent on timing, because it's only updated once every second or, if the toal is known in advance, every 1%, and there is the throughput rate as well. These make the progress display far too undeterministic for testing as-is. To address this, add a few testing-specific variables and functions to 'progress.c', allowing the the new test helper to: - Disable the triggered-every-second SIGALRM and set the 'progress_update' flag explicitly based in the input instructions. This way the progress line will be updated deterministically when the test wants it to be updated. - Specify the time elapsed since start_progress() to make the throughput rate calculations deterministic. Add the new test script 't0500-progress-display.sh' to check a few simple cases with and without throughput, and that a shorter progress line properly covers up the previously displayed line in different situations. [1] See commits 545dc345eb (progress: break too long progress bar lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous progress update dynamically, 2019-04-12). [2] 1aed1a5f25 (progress: avoid empty line when breaking the progress line, 2019-05-19) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-17Revert "progress: use term_clear_line()"Libravatar SZEDER Gábor1-3/+3
This reverts commit 5b12e3123b (progress: use term_clear_line(), 2019-06-24), because covering up the entire last line while refreshing the progress line caused unexpected problems during 'git clone/fetch/push': $ git clone ssh://localhost/home/szeder/src/tmp/linux.git/ Cloning into 'linux'... remote: remote: remote: remote: Enumerating objects: 999295 The length of the progress bar line can shorten when it includes throughput and the unit changes, or when its length exceeds the width of the terminal and is broken into two lines. In these cases the previously displayed longer progress line should be covered up, because otherwise the leftover characters from the previous progress line make the output look weird [1]. term_clear_line() makes this quite simple, as it covers up the entire last line either by using an ANSI control sequence or by printing a terminal width worth of space characters, depending on whether the terminal is smart or dumb. Unfortunately, when accessing a remote repository via any non-local protocol the remote 'git receive-pack/upload-pack' processes can't possibly have any idea about the local terminal (smart of dumb? how wide?) their progress will end up on. Consequently, they assume the worst, i.e. standard-width dumb terminal, and print 80 spaces to cover up the previously displayed progress line. The local 'git clone/fetch/push' processes then display the remote's progress, including these coverup spaces, with the 'remote: ' prefix, resulting in a total line length of 88 characters. If the local terminal is narrower than that, then the coverup gets line-wrapped, and after that the CR at the end doesn't return to the beginning of the progress line, but to the first column of its last line, resulting in those repeated 'remote: <many-spaces>' lines. By reverting 5b12e3123b (progress: use term_clear_line(), 2019-06-24) we won't cover up the entire last line, but go back to comparing the length of the current progress bar line with the previous one, and cover up as many characters as needed. [1] See commits 545dc345eb (progress: break too long progress bar lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous progress update dynamically, 2019-04-12). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16sha1-name: check for overflow of N in "foo^N" and "foo~N"Libravatar René Scharfe1-2/+2
Reject values that don't fit into an int, as get_parent() and get_nth_ancestor() cannot handle them. That's better than potentially returning a random object. If this restriction turns out to be too tight then we can switch to a wider data type, but we'd still have to check for overflow. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16rev-parse: demonstrate overflow of N for "foo^N" and "foo~N"Libravatar René Scharfe1-0/+8
If the number gets too high for an int, weird things may happen, as signed overflows are undefined. Add a test to show this; rev-parse "sucessfully" interprets 100000000000000000000000000000000 to be the same as 0, at least on x64 with GCC 9.2.1 and Clang 8.0.1, which is obviously bogus. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16list-objects-filter: give a more specific error sparse parsing errorLibravatar Jon Simons1-1/+1
The sparse:oid filter has two error modes: we might fail to resolve the name to an OID, or we might fail to parse the contents of that OID. In the latter case, let's give a less generic error message, and mention the OID we did find. While we're here, let's also mark both messages as translatable. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16list-objects-filter: delay parsing of sparse oidLibravatar Jeff King1-2/+2
The list-objects-filter code has two steps to its initialization: 1. parse_list_objects_filter() makes sure the spec is a filter we know about and is syntactically correct. This step is done by "rev-list" or "upload-pack" that is going to apply a filter, but also by "git clone" or "git fetch" before they send the spec across the wire. 2. list_objects_filter__init() runs the type-specific initialization (using function pointers established in step 1). This happens at the start of traverse_commit_list_filtered(), when we're about to actually use the filter. It's a good idea to parse as much as we can in step 1, in order to catch problems early (e.g., a blob size limit that isn't a number). But one thing we _shouldn't_ do is resolve any oids at that step (e.g., for sparse-file contents specified by oid). In the case of a fetch, the oid has to be resolved on the remote side. The current code does resolve the oid during the parse phase, but ignores any error (which we must do, because we might just be sending the spec across the wire). This leads to two bugs: - if we're not in a repository (e.g., because it's git-clone parsing the spec), then we trigger a BUG() trying to resolve the name - if we did hit the error case, we still have to notice that later and bail. The code path in rev-list handles this, but the one in upload-pack does not, leading to a segfault. We can fix both by moving the oid resolution into the sparse-oid init function. At that point we know we have a repository (because we're about to traverse), and handling the error there fixes the segfault. As a bonus, we can drop the NULL sparse_oid_value check in rev-list, since this is now handled in the sparse-oid-filter init function. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16t5616: test cloning/fetching with sparse:oid=<oid> filterLibravatar Jon Simons1-0/+36
We test in t5317 that "sparse:oid" filters work with rev-list, but there's no coverage at all confirming that they work with a fetch or clone (and in fact, there are several bugs). Let's do a basic test that a clone fetches the correct objects. [jk: extracted from Jon's earlier fix patches. I also simplified the setup down to a single sparse file, and I added checks that we got the right blobs] Signed-off-by: Jon Simons <jon@jonsimons.org> Signed-off-by: Jeff King <peff@peff.net> Acked-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-12upload-pack: disable commit graph more gently for shallow traversalLibravatar Jeff King1-0/+38
When the client has asked for certain shallow options like "deepen-since", we do a custom rev-list walk that pretends to be shallow. Before doing so, we have to disable the commit-graph, since it is not compatible with the shallow view of the repository. That's handled by 829a321569 (commit-graph: close_commit_graph before shallow walk, 2018-08-20). That commit literally closes and frees our repo->objects->commit_graph struct. That creates an interesting problem for commits that have _already_ been parsed using the commit graph. Their commit->object.parsed flag is set, their commit->graph_pos is set, but their commit->maybe_tree may still be NULL. When somebody later calls repo_get_commit_tree(), we see that we haven't loaded the tree oid yet and try to get it from the commit graph. But since it has been freed, we segfault! So the root of the issue is a data dependency between the commit's lazy-load of the tree oid and the fact that the commit graph can go away mid-process. How can we resolve it? There are a couple of general approaches: 1. The obvious answer is to avoid loading the tree from the graph when we see that it's NULL. But then what do we return for the tree oid? If we return NULL, our caller in do_traverse() will rightly complain that we have no tree. We'd have to fallback to loading the actual commit object and re-parsing it. That requires teaching parse_commit_buffer() to understand re-parsing (i.e., not starting from a clean slate and not leaking any allocated bits like parent list pointers). 2. When we close the commit graph, walk through the set of in-memory objects and clear any graph_pos pointers. But this means we also have to "unparse" any such commits so that we know they still need to open the commit object to fill in their trees. So it's no less complicated than (1), and is more expensive (since we clear objects we might not later need). 3. Stop freeing the commit-graph struct. Continue to let it be used for lazy-loads of tree oids, but let upload-pack specify that it shouldn't be used for further commit parsing. 4. Push the whole shallow rev-list out to its own sub-process, with the commit-graph disabled from the start, giving it a clean memory space to work from. I've chosen (3) here. Options (1) and (2) would work, but are non-trivial to implement. Option (4) is more expensive, and I'm not sure how complicated it is (shelling out for the actual rev-list part is easy, but we do then parse the resulting commits internally, and I'm not clear which parts need to be handling shallow-ness). The new test in t5500 triggers this segfault, but see the comments there for how horribly intimate it has to be with how both upload-pack and commit graphs work. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-12Quit passing 'now' to date codeLibravatar Stephen P. Smith1-17/+9
Commit b841d4ff43 (Add `human` format to test-tool, 2019-01-28) added a get_time() function which allows $GIT_TEST_DATE_NOW in the environment to override the current time. So we no longer need to interpret that variable in cmd__date(). Therefore, we can stop passing the "now" parameter down through the date functions, since nobody uses them. Note that we do need to make sure all of the previous callers that took a "now" parameter are correctly using get_time(). Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-09cache-tree: do not lazy-fetch tentative treeLibravatar Jonathan Tan1-0/+14
The cache-tree datastructure is used to speed up the comparison between the HEAD and the index, and when the index is updated by a cherry-pick (for example), a tree object that would represent the paths in the index in a directory is constructed in-core, to see if such a tree object exists already in the object store. When the lazy-fetch mechanism was introduced, we converted this "does the tree exist?" check into an "if it does not, and if we lazily cloned, see if the remote has it" call by mistake. Since the whole point of this check is to repair the cache-tree by recording an already existing tree object opportunistically, we shouldn't even try to fetch one from the remote. Pass the OBJECT_INFO_SKIP_FETCH_OBJECT flag to make sure we only check for existence in the local object store without triggering the lazy fetch mechanism. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> [jc: rewritten the proposed log message] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-09Merge branch 'bc/reread-attributes-during-rebase'Libravatar Junio C Hamano2-0/+88
The "git am" based backend of "git rebase" ignored the result of updating ".gitattributes" done in one step when replaying subsequent steps. * bc/reread-attributes-during-rebase: am: reload .gitattributes after patching it path: add a function to check for path suffix