summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2018-09-24Merge branch 'en/rerere-multi-stage-1-fix'Libravatar Junio C Hamano1-0/+29
A corner case bugfix in "git rerere" code. * en/rerere-multi-stage-1-fix: rerere: avoid buffer overrun t4200: demonstrate rerere segfault on specially crafted merge
2018-09-24Merge branch 'js/mingw-o-append'Libravatar Junio C Hamano4-0/+95
Further fix for O_APPEND emulation on Windows * js/mingw-o-append: mingw: fix mingw_open_append to work with named pipes t0051: test GIT_TRACE to a windows named pipe
2018-09-24Merge branch 'jk/reopen-tempfile-truncate'Libravatar Junio C Hamano1-0/+18
Fix for a long-standing bug that leaves the index file corrupt when it shrinks during a partial commit. * jk/reopen-tempfile-truncate: reopen_tempfile(): truncate opened file
2018-09-24Merge branch 'ds/format-patch-range-diff-test'Libravatar Junio C Hamano1-0/+5
* ds/format-patch-range-diff-test: t3206-range-diff.sh: cover single-patch case
2018-09-24Merge branch 'js/rebase-i-autosquash-fix'Libravatar Junio C Hamano1-0/+19
"git rebase -i" did not clear the state files correctly when a run of "squash/fixup" is aborted and then the user manually amended the commit instead, which has been corrected. * js/rebase-i-autosquash-fix: rebase -i: be careful to wrap up fixup/squash chains rebase -i --autosquash: demonstrate a problem skipping the last squash
2018-09-17Merge branch 'ab/fetch-tags-noclobber'Libravatar Junio C Hamano2-4/+29
The rules used by "git push" and "git fetch" to determine if a ref can or cannot be updated were inconsistent; specifically, fetching to update existing tags were allowed even though tags are supposed to be unmoving anchoring points. "git fetch" was taught to forbid updates to existing tags without the "--force" option. * ab/fetch-tags-noclobber: fetch: stop clobbering existing tags without --force fetch: document local ref updates with/without --force push doc: correct lies about how push refspecs work push doc: move mention of "tag <tag>" later in the prose push doc: remove confusing mention of remote merger fetch tests: add a test for clobbering tag behavior push tests: use spaces in interpolated string push tests: make use of unused $1 in test description fetch: change "branch" to "reference" in --force -h output
2018-09-17Merge branch 'es/worktree-forced-ops-fix'Libravatar Junio C Hamano2-0/+62
Fix a bug in which the same path could be registered under multiple worktree entries if the path was missing (for instance, was removed manually). Also, as a convenience, expand the number of cases in which --force is applicable. * es/worktree-forced-ops-fix: doc-diff: force worktree add worktree: delete .git/worktrees if empty after 'remove' worktree: teach 'remove' to override lock when --force given twice worktree: teach 'move' to override lock when --force given twice worktree: teach 'add' to respect --force for registered but missing path worktree: disallow adding same path multiple times worktree: prepare for more checks of whether path can become worktree worktree: generalize delete_git_dir() to reduce code duplication worktree: move delete_git_dir() earlier in file for upcoming new callers worktree: don't die() in library function find_worktree()
2018-09-17Merge branch 'jk/patch-corrupted-delta-fix'Libravatar Junio C Hamano2-4/+93
Malformed or crafted data in packstream can make our code attempt to read or write past the allocated buffer and abort, instead of reporting an error, which has been fixed. * jk/patch-corrupted-delta-fix: t5303: use printf to generate delta bases patch-delta: handle truncated copy parameters patch-delta: consistently report corruption patch-delta: fix oob read t5303: test some corrupt deltas test-delta: read input into a heap buffer
2018-09-17Merge branch 'ds/commit-graph-tests'Libravatar Junio C Hamano5-10/+13
We can now optionally run tests with commit-graph enabled. * ds/commit-graph-tests: commit-graph: define GIT_TEST_COMMIT_GRAPH
2018-09-17Merge branch 'jk/pack-objects-with-bitmap-fix'Libravatar Junio C Hamano1-0/+93
Hotfix of the base topic. * jk/pack-objects-with-bitmap-fix: pack-bitmap: drop "loaded" flag traverse_bitmap_commit_list(): don't free result t5310: test delta reuse with bitmaps bitmap_has_sha1_in_uninteresting(): drop BUG check
2018-09-17Merge branch 'rs/mailinfo-format-flowed'Libravatar Junio C Hamano4-0/+2578
"git mailinfo" used in "git am" learned to make a best-effort recovery of a patch corrupted by MUA that sends text/plain with format=flawed option. * rs/mailinfo-format-flowed: mailinfo: support format=flowed
2018-09-17Merge branch 'jk/cocci'Libravatar Junio C Hamano1-1/+1
spatch transformation to replace boolean uses of !hashcmp() to newly introduced oideq() is added, and applied, to regain performance lost due to support of multiple hash algorithms. * jk/cocci: show_dirstat: simplify same-content check read-cache: use oideq() in ce_compare functions convert hashmap comparison functions to oideq() convert "hashcmp() != 0" to "!hasheq()" convert "oidcmp() != 0" to "!oideq()" convert "hashcmp() == 0" to hasheq() convert "oidcmp() == 0" to oideq() introduce hasheq() and oideq() coccinelle: use <...> for function exclusion
2018-09-17Merge branch 'es/format-patch-rangediff'Libravatar Junio C Hamano1-0/+12
"git format-patch" learned a new "--range-diff" option to explain the difference between this version and the previous attempt in the cover letter (or after the tree-dashes as a comment). * es/format-patch-rangediff: format-patch: allow --range-diff to apply to a lone-patch format-patch: add --creation-factor tweak for --range-diff format-patch: teach --range-diff to respect -v/--reroll-count format-patch: extend --range-diff to accept revision range format-patch: add --range-diff option to embed diff in cover letter range-diff: relieve callers of low-level configuration burden range-diff: publish default creation factor range-diff: respect diff_option.file rather than assuming 'stdout'
2018-09-17Merge branch 'es/format-patch-interdiff'Libravatar Junio C Hamano1-0/+34
"git format-patch" learned a new "--interdiff" option to explain the difference between this version and the previous atttempt in the cover letter (or after the tree-dashes as a comment). * es/format-patch-interdiff: format-patch: allow --interdiff to apply to a lone-patch log-tree: show_log: make commentary block delimiting reusable interdiff: teach show_interdiff() to indent interdiff format-patch: teach --interdiff to respect -v/--reroll-count format-patch: add --interdiff option to embed diff in cover letter format-patch: allow additional generated content in make_cover_letter()
2018-09-17Merge branch 'cc/delta-islands'Libravatar Junio C Hamano1-0/+143
Lift code from GitHub to restrict delta computation so that an object that exists in one fork is not made into a delta against another object that does not appear in the same forked repository. * cc/delta-islands: pack-objects: move 'layer' into 'struct packing_data' pack-objects: move tree_depth into 'struct packing_data' t5320: tests for delta islands repack: add delta-islands support pack-objects: add delta-islands support pack-objects: refactor code into compute_layer_order() Add delta-islands.{c,h}
2018-09-17Merge branch 'jk/trailer-fixes'Libravatar Junio C Hamano4-0/+104
"git interpret-trailers" and its underlying machinery had a buggy code that attempted to ignore patch text after commit log message, which triggered in various codepaths that will always get the log message alone and never get such an input. * jk/trailer-fixes: append_signoff: use size_t for string offsets sequencer: ignore "---" divider when parsing trailers pretty, ref-filter: format %(trailers) with no_divider option interpret-trailers: allow suppressing "---" divider interpret-trailers: tighten check for "---" patch boundary trailer: pass process_trailer_opts to trailer_info_get() trailer: use size_t for iterating trailer list trailer: use size_t for string offsets
2018-09-17Merge branch 'sb/range-diff-colors'Libravatar Junio C Hamano2-3/+44
The color output support for recently introduced "range-diff" command got tweaked a bit. * sb/range-diff-colors: range-diff: indent special lines as context range-diff: make use of different output indicators diff.c: add --output-indicator-{new, old, context} diff.c: rewrite emit_line_0 more understandably diff.c: omit check for line prefix in emit_line_0 diff: use emit_line_0 once per line diff.c: add set_sign to emit_line_0 diff.c: reorder arguments for emit_line_ws_markup diff.c: simplify caller of emit_line_0 t3206: add color test for range-diff --dual-color test_decode_color: understand FAINT and ITALIC
2018-09-17Merge branch 'jk/pack-delta-reuse-with-bitmap'Libravatar Junio C Hamano4-40/+173
When creating a thin pack, which allows objects to be made into a delta against another object that is not in the resulting pack but is known to be present on the receiving end, the code learned to take advantage of the reachability bitmap; this allows the server to send a delta against a base beyond the "boundary" commit. * jk/pack-delta-reuse-with-bitmap: pack-objects: reuse on-disk deltas for thin "have" objects pack-bitmap: save "have" bitmap from walk t/perf: add perf tests for fetches from a bitmapped server t/perf: add infrastructure for measuring sizes t/perf: factor out percent calculations t/perf: factor boilerplate out of test_perf
2018-09-17Merge branch 'nd/unpack-trees-with-cache-tree'Libravatar Junio C Hamano2-0/+10
The unpack_trees() API used in checking out a branch and merging walks one or more trees along with the index. When the cache-tree in the index tells us that we are walking a tree whose flattened contents is known (i.e. matches a span in the index), as linearly scanning a span in the index is much more efficient than having to open tree objects recursively and listing their entries, the walk can be optimized, which is done in this topic. * nd/unpack-trees-with-cache-tree: Document update for nd/unpack-trees-with-cache-tree cache-tree: verify valid cache-tree in the test suite unpack-trees: add missing cache invalidation unpack-trees: reuse (still valid) cache-tree from src_index unpack-trees: reduce malloc in cache-tree walk unpack-trees: optimize walking same trees with cache-tree unpack-trees: add performance tracing trace.h: support nested performance tracing
2018-09-17Merge branch 'ds/reachable'Libravatar Junio C Hamano4-0/+374
The code for computing history reachability has been shuffled, obtained a bunch of new tests to cover them, and then being improved. * ds/reachable: commit-reach: correct accidental #include of C file commit-reach: use can_all_from_reach commit-reach: make can_all_from_reach... linear commit-reach: replace ref_newer logic test-reach: test commit_contains test-reach: test can_all_from_reach_with_flags test-reach: test reduce_heads test-reach: test get_merge_bases_many test-reach: test is_descendant_of test-reach: test in_merge_bases test-reach: create new test tool for ref_newer commit-reach: move can_all_from_reach_with_flags upload-pack: generalize commit date cutoff upload-pack: refactor ok_to_give_up() upload-pack: make reachable() more generic commit-reach: move commit_contains from ref-filter commit-reach: move ref_newer from remote.c commit.h: remove method declarations commit-reach: move walk methods from commit.c
2018-09-17Merge branch 'tg/rerere'Libravatar Junio C Hamano1-0/+65
Fixes to "git rerere" corner cases, especially when conflict markers cannot be parsed in the file. * tg/rerere: rerere: recalculate conflict ID when unresolved conflict is committed rerere: teach rerere to handle nested conflicts rerere: return strbuf from handle path rerere: factor out handle_conflict function rerere: only return whether a path has conflicts or not rerere: fix crash with files rerere can't handle rerere: add documentation for conflict normalization rerere: mark strings for translation rerere: wrap paths in output in sq rerere: lowercase error messages rerere: unify error messages when read_cache fails
2018-09-17Merge branch 'ds/multi-pack-index'Libravatar Junio C Hamano4-0/+270
When there are too many packfiles in a repository (which is not recommended), looking up an object in these would require consulting many pack .idx files; a new mechanism to have a single file that consolidates all of these .idx files is introduced. * ds/multi-pack-index: (32 commits) pack-objects: consider packs in multi-pack-index midx: test a few commands that use get_all_packs treewide: use get_all_packs packfile: add all_packs list midx: fix bug that skips midx with alternates midx: stop reporting garbage midx: mark bad packed objects multi-pack-index: store local property multi-pack-index: provide more helpful usage info midx: clear midx on repack packfile: skip loading index if in multi-pack-index midx: prevent duplicate packfile loads midx: use midx in approximate_object_count midx: use existing midx when writing new one midx: use midx in abbreviation calculations midx: read objects from multi-pack-index config: create core.multiPackIndex setting midx: write object offsets midx: write object id fanout chunk midx: write object ids in a chunk ...
2018-09-17Merge branch 'jk/rev-list-stdin-noop-is-ok'Libravatar Junio C Hamano1-1/+1
"git rev-list --stdin </dev/null" used to be an error; it now shows no output without an error. "git rev-list --stdin --default HEAD" still falls back to the given default when nothing is given on the standard input. * jk/rev-list-stdin-noop-is-ok: rev-list: make empty --stdin not an error
2018-09-17Merge branch 'bp/checkout-new-branch-optim'Libravatar Junio C Hamano1-0/+14
"git checkout -b newbranch [HEAD]" should not have to do as much as checking out a commit different from HEAD. An attempt is made to optimize this special case. * bp/checkout-new-branch-optim: checkout: optimize "git checkout -b <new_branch>"
2018-09-17Merge branch 'sg/t1404-update-ref-test-timeout'Libravatar Junio C Hamano1-3/+3
An attempt to unflake a test a bit. * sg/t1404-update-ref-test-timeout: t1404: increase core.packedRefsTimeout to avoid occasional test failure
2018-09-17Merge branch 'nd/clone-case-smashing-warning'Libravatar Junio C Hamano1-1/+7
Running "git clone" against a project that contain two files with pathnames that differ only in cases on a case insensitive filesystem would result in one of the files lost because the underlying filesystem is incapable of holding both at the same time. An attempt is made to detect such a case and warn. * nd/clone-case-smashing-warning: clone: report duplicate entries on case-insensitive filesystems
2018-09-17Merge branch 'mk/http-backend-content-length'Libravatar Junio C Hamano1-2/+2
Test update. * mk/http-backend-content-length: http-backend test: make empty CONTENT_LENGTH test more realistic
2018-09-12t3206-range-diff.sh: cover single-patch caseLibravatar Derrick Stolee1-0/+5
The commit 40ce4160 "format-patch: allow --range-diff to apply to a lone-patch" added the ability to see a range-diff as commentary after the commit message of a single patch series (i.e. [PATCH] instead of [PATCH X/N]). However, this functionality was not covered by a test case. Add a simple test case that checks that a range-diff is written as commentary to the patch. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-11http-backend test: make empty CONTENT_LENGTH test more realisticLibravatar Max Kirillov1-2/+2
This is a test of smart HTTP, so it should use the smart HTTP endpoints (e.g. /info/refs?service=git-receive-pack), not dumb HTTP (HEAD). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-11mingw: fix mingw_open_append to work with named pipesLibravatar Jeff Hostetler1-1/+1
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-11t0051: test GIT_TRACE to a windows named pipeLibravatar Jeff Hostetler4-0/+95
Create a test-tool helper to create the server side of a windows named pipe, wait for a client connection, and copy data written to the pipe to stdout. Create t0051 test to route GIT_TRACE output of a command to a named pipe using the above test-tool helper. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-11rerere: avoid buffer overrunLibravatar Elijah Newren1-1/+1
check_one_conflict() compares `i` to `active_nr` in two places to avoid buffer overruns, but left out an important third location. The code did used to have a check here comparing i to active_nr, back before commit fb70a06da2f1 ("rerere: fix an off-by-one non-bug", 2015-06-28), however the code at the time used an 'if' rather than a 'while' meaning back then that this loop could not have read past the end of the array, making the check unnecessary and it was removed. Unfortunately, in commit 5eda906b2873 ("rerere: handle conflicts with multiple stage #1 entries", 2015-07-24), the 'if' was changed to a 'while' and the check comparing i and active_nr was not re-instated, leading to this problem. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-11t4200: demonstrate rerere segfault on specially crafted mergeLibravatar Elijah Newren1-0/+29
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-10Merge branch 'jn/submodule-core-worktree-revert'Libravatar Junio C Hamano2-8/+2
* jn/submodule-core-worktree-revert: Revert "Merge branch 'sb/submodule-core-worktree'"
2018-09-10Merge branch 'mk/http-backend-content-length'Libravatar Junio C Hamano1-0/+11
The earlier attempt barfed when given a CONTENT_LENGTH that is set to an empty string. RFC 3875 is fairly clear that in this case we should not read any message body, but we've been reading through to the EOF in previous versions (which did not even pay attention to the environment variable), so keep that behaviour for now in this late update. * mk/http-backend-content-length: http-backend: allow empty CONTENT_LENGTH
2018-09-07Revert "Merge branch 'sb/submodule-core-worktree'"Libravatar Jonathan Nieder2-8/+2
This reverts commit 7e25437d35a70791b345872af202eabfb3e1a8bc, reversing changes made to 00624d608cc69bd62801c93e74d1ea7a7ddd6598. v2.19.0-rc0~165^2~1 (submodule: ensure core.worktree is set after update, 2018-06-18) assumes an "absorbed" submodule layout, where the submodule's Git directory is in the superproject's .git/modules/ directory and .git in the submodule worktree is a .git file pointing there. In particular, it uses $GIT_DIR/modules/$name to find the submodule to find out whether it already has core.worktree set, and it uses connect_work_tree_and_git_dir if not, resulting in fatal: could not open sub/.git for writing The context behind that patch: v2.19.0-rc0~165^2~2 (submodule: unset core.worktree if no working tree is present, 2018-06-12) unsets core.worktree when running commands like "git checkout --recurse-submodules" to switch to a branch without the submodule. If a user then uses "git checkout --no-recurse-submodules" to switch back to a branch with the submodule and runs "git submodule update", this patch is needed to ensure that commands using the submodule directly are aware of the path to the worktree. It is late in the release cycle, so revert the whole 3-patch series. We can try again later for 2.20. Reported-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-07http-backend: allow empty CONTENT_LENGTHLibravatar Max Kirillov1-0/+11
According to RFC3875, empty environment variable is equivalent to unset, and for CONTENT_LENGTH it should mean zero body to read. However, unset CONTENT_LENGTH is also used for chunked encoding to indicate reading until EOF. At least, the test "large fetch-pack requests can be split across POSTs" from t5551 starts faliing, if unset or empty CONTENT_LENGTH is treated as zero length body. So keep the existing behavior as much as possible. Add a test for the case. Reported-By: Jelmer Vernooij <jelmer@jelmer.uk> Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-05reopen_tempfile(): truncate opened fileLibravatar Jeff King1-0/+18
We provide a reopen_tempfile() function, which is in turn used by reopen_lockfile(). The idea is that a caller may want to rewrite the tempfile without letting go of the lock. And that's what our one caller does: after running add--interactive, "commit -p" will update the cache-tree extension of the index and write out the result, all while holding the lock. However, because we open the file with only the O_WRONLY flag, the existing index content is left in place, and we overwrite it starting at position 0. If the new index after updating the cache-tree is smaller than the original, those final bytes are not overwritten and remain in the file. This results in a corrupt index, since those cruft bytes are interpreted as part of the trailing hash (or even as an extension, if there are enough bytes). This bug actually pre-dates reopen_tempfile(); the original code from 9c4d6c0297 (cache-tree: Write updated cache-tree after commit, 2014-07-13) has the same bug, and those lines were eventually refactored into the tempfile module. Nobody noticed until now for two reasons: - the bug can only be triggered in interactive mode ("commit -p" or "commit -i") - the size of the index must shrink after updating the cache-tree, which implies a non-trivial deletion. Notice that the included test actually has to create a 2-deep hierarchy. A single level is not enough to actually cause shrinkage. The fix is to truncate the file before writing out the second index. We can do that at the caller by using ftruncate(). But we shouldn't have to do that. There is no other place in Git where we want to open a file and overwrite bytes, making reopen_tempfile() a confusing and error-prone interface. Let's pass O_TRUNC there, which gives callers the same state they had after initially opening the file or lock. It's possible that we could later add a caller that wants something else (e.g., to open with O_APPEND). But this is the only caller we've had in the history of the codebase. Let's punt on doing anything more clever until another one comes along. Reported-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-04Merge branch 'es/chain-lint-more'Libravatar Junio C Hamano5-4/+18
The test linter code has learned that the end of here-doc mark "EOF" can be quoted in a double-quote pair, not just in a single-quote pair. * es/chain-lint-more: chainlint: match "quoted" here-doc tags
2018-09-04Merge branch 'ab/portable-more'Libravatar Junio C Hamano10-44/+53
Portability fix. * ab/portable-more: tests: fix non-portable iconv invocation tests: fix non-portable "${var:-"str"}" construct tests: fix and add lint for non-portable grep --file tests: fix version-specific portability issue in Perl JSON tests: use shorter labels in chainlint.sed for AIX sed tests: fix comment syntax in chainlint.sed for AIX sed tests: fix and add lint for non-portable seq tests: fix and add lint for non-portable head -c N
2018-09-04Merge branch 'en/directory-renames-nothanks'Libravatar Junio C Hamano1-1/+109
Recent addition of "directory rename" heuristics to the merge-recursive backend makes the command susceptible to false positives and false negatives. In the context of "git am -3", which does not know about surrounding unmodified paths and thus cannot inform the merge machinery about the full trees involved, this risk is particularly severe. As such, the heuristic is disabled for "git am -3" to keep the machinery "more stupid but predictable". * en/directory-renames-nothanks: am: avoid directory rename detection when calling recursive merge machinery merge-recursive: add ability to turn off directory rename detection t3401: add another directory rename testcase for rebase and am
2018-09-04Merge branch 'pw/rebase-i-author-script-fix'Libravatar Junio C Hamano1-3/+15
Recent "git rebase -i" update started to write bogusly formatted author-script, with a matching broken reading code. These are fixed. * pw/rebase-i-author-script-fix: sequencer: fix quoting in write_author_script sequencer: handle errors from read_author_ident()
2018-09-04rebase -i: be careful to wrap up fixup/squash chainsLibravatar Johannes Schindelin1-1/+1
When an interactive rebase was stopped at the end of a fixup/squash chain, the user might have edited the commit manually before continuing (with either `git rebase --skip` or `git rebase --continue`, it does not really matter which). We need to be very careful to wrap up the fixup/squash chain also in this scenario: otherwise the next fixup/squash chain would try to pick up where the previous one was left. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2018-09-04rebase -i --autosquash: demonstrate a problem skipping the last squashLibravatar Johannes Schindelin1-0/+19
The `git commit --squash` command can be used not only to amend commit messages and changes, but also to record notes for an upcoming rebase. For example, when the author information of a given commit is incorrect, a user might call `git commit --allow-empty -m "Fix author" --squash <commit>`, to remind them to fix that during the rebase. When the editor would pop up, the user would simply delete the commit message to abort the rebase at this stage, fix the author information, and continue with `git rebase --skip`. (This is a real-world example from the rebase of Git for Windows onto v2.19.0-rc1.) However, there is a bug in `git rebase` that will cause the squash message *not* to be forgotten in this case. It will therefore be reused in the next fixup/squash chain (if any). This patch adds a test case to demonstrate this breakage. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2018-09-04t5310: test delta reuse with bitmapsLibravatar Jeff King1-0/+93
Commit 6a1e32d532 (pack-objects: reuse on-disk deltas for thin "have" objects, 2018-08-21) taught pack-objects a new optimization trick. Since this wasn't meant to change user-visible behavior, but only produce smaller packs more quickly, testing focused on t/perf/p5311. However, since people don't run perf tests very often, we should make sure that the feature is exercised in the regular test suite. This patch does so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31fetch: stop clobbering existing tags without --forceLibravatar Ævar Arnfjörð Bjarmason2-4/+5
Change "fetch" to treat "+" in refspecs (aka --force) to mean we should clobber a local tag of the same name. This changes the long-standing behavior of "fetch" added in 853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20). Before this change, all tag fetches effectively had --force enabled. See the git-fetch-script code in fast_forward_local() with the comment: > Tags need not be pointing at commits so there is no way to > guarantee "fast-forward" anyway. That commit and the rest of the history of "fetch" shows that the "+" (--force) part of refpecs was only conceived for branch updates, while tags have accepted any changes from upstream unconditionally and clobbered the local tag object. Changing this behavior has been discussed as early as 2011[1]. The current behavior doesn't make sense to me, it easily results in local tags accidentally being clobbered. We could namespace our tags per-remote and not locally populate refs/tags/*, but as with my 97716d217c ("fetch: add a --prune-tags option and fetch.pruneTags config", 2018-02-09) it's easier to work around the current implementation than to fix the root cause. So this change implements suggestion #1 from Jeff's 2011 E-Mail[1], "fetch" now only clobbers the tag if either "+" is provided as part of the refspec, or if "--force" is provided on the command-line. This also makes it nicely symmetrical with how "tag" itself works when creating tags. I.e. we refuse to clobber any existing tags unless "--force" is supplied. Now we can refuse all such clobbering, whether it would happen by clobbering a local tag with "tag", or by fetching it from the remote with "fetch". Ref updates outside refs/{tags,heads/* are still still not symmetrical with how "git push" works, as discussed in the recently changed pull-fetch-param.txt documentation. This change brings the two divergent behaviors more into line with one another. I don't think there's any reason "fetch" couldn't fully converge with the behavior used by "push", but that's a topic for another change. One of the tests added in 31b808a032 ("clone --single: limit the fetch refspec to fetched branch", 2012-09-20) is being changed to use --force where a clone would clobber a tag. This changes nothing about the existing behavior of the test. 1. https://public-inbox.org/git/20111123221658.GA22313@sigill.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31fetch tests: add a test for clobbering tag behaviorLibravatar Ævar Arnfjörð Bjarmason1-0/+24
The test suite only incidentally (and unintentionally) tested for the current behavior of eager tag clobbering on "fetch". This is a followup to 380efb65df ("push tests: assert re-pushing annotated tags", 2018-07-31) which tests for it explicitly. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31push tests: use spaces in interpolated stringLibravatar Ævar Arnfjörð Bjarmason1-1/+1
The quoted -m'msg' option would mean the same as -mmsg when passed through the test_force_push_tag helper. Let's instead use a string with spaces in it, to have a working example in case we need to pass other whitespace-delimited arguments to git-tag. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31push tests: make use of unused $1 in test descriptionLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Fix up a logic error in 380efb65df ("push tests: assert re-pushing annotated tags", 2018-07-31), where the $tag_type_description variable was assigned to but never used, unlike in the subsequently added companion test for fetches in 2d216a7ef6 ("fetch tests: add a test for clobbering tag behavior", 2018-04-29). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30t5303: use printf to generate delta basesLibravatar Jeff King1-10/+10
The exact byte count of the delta base file is important. The test-delta helper will feed it to patch_delta(), which will barf if it doesn't match the size byte given in the delta. Using "echo" may end up with unexpected line endings on some platforms (e.g,. "\r\n" instead of just "\n"). This actually wouldn't cause the test to fail (since we already expect test-delta to complain about these bogus deltas), but would mean that we're not exercising the code we think we are. Let's use printf instead (which we already trust to give us byte-perfect output when we generate the deltas). While we're here, let's tighten the 5-byte result size used in the "truncated copy parameters" test. This just needs to have enough room to attempt to parse the bogus copy command, meaning 2 is sufficient. Using 5 was arbitrary and just copied from the base size; since those no longer match, it's simply confusing. Let's use a more meaningful number. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>