summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-04-02t: rename t2014-switch.sh to t2014-checkout-switch.shLibravatar Nguyễn Thái Ngọc Duy1-0/+0
The old name does not really say that this is about 'checkout -b'. See 49d833dc07 (Revert "checkout branch: prime cache-tree fully" - 2009-05-12) for more information Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07Merge branch 'jt/http-auth-proto-v2-fix'Libravatar Junio C Hamano1-1/+32
Unify RPC code for smart http in protocol v0/v1 and v2, which fixes a bug in the latter (lack of authentication retry) and generally improves the code base. * jt/http-auth-proto-v2-fix: remote-curl: use post_rpc() for protocol v2 also remote-curl: refactor reading into rpc_state's buf remote-curl: reduce scope of rpc_state.result remote-curl: reduce scope of rpc_state.stdin_preamble remote-curl: reduce scope of rpc_state.argv
2019-03-07Merge branch 'jk/diff-no-index-initialize'Libravatar Junio C Hamano1-0/+8
"git diff --no-index" may still want to access Git goodies like --ext-diff and --textconv, but so far these have been ignored, which has been corrected. * jk/diff-no-index-initialize: diff: reuse diff setup for --no-index case
2019-03-07Merge branch 'jk/prune-optim'Libravatar Junio C Hamano2-8/+55
"git prune" has been taught to take advantage of reachability bitmap when able. * jk/prune-optim: t5304: rename "sha1" variables to "oid" prune: check SEEN flag for reachability prune: use bitmaps for reachability traversal prune: lazily perform reachability traversal
2019-03-07Merge branch 'jh/trace2'Libravatar Junio C Hamano11-0/+1181
A more structured way to obtain execution trace has been added. * jh/trace2: trace2: add for_each macros to clang-format trace2: t/helper/test-trace2, t0210.sh, t0211.sh, t0212.sh trace2:data: add subverb for rebase trace2:data: add subverb to reset command trace2:data: add subverb to checkout command trace2:data: pack-objects: add trace2 regions trace2:data: add trace2 instrumentation to index read/write trace2:data: add trace2 hook classification trace2:data: add trace2 transport child classification trace2:data: add trace2 sub-process classification trace2:data: add editor/pager child classification trace2:data: add trace2 regions to wt-status trace2: collect Windows-specific process information trace2: create new combined trace facility trace2: Documentation/technical/api-trace2.txt
2019-03-07Merge branch 'nd/split-index-null-base-fix'Libravatar Junio C Hamano1-0/+18
Split-index fix. * nd/split-index-null-base-fix: read-cache.c: fix writing "link" index ext with null base oid
2019-03-07Merge branch 'jc/test-yes-doc'Libravatar Junio C Hamano2-1/+14
Test doc update. * jc/test-yes-doc: test: caution on our version of 'yes'
2019-03-07Merge branch 'en/combined-all-paths'Libravatar Junio C Hamano1-0/+88
Output from "diff --cc" did not show the original paths when the merge involved renames. A new option adds the paths in the original trees to the output. * en/combined-all-paths: log,diff-tree: add --combined-all-paths option
2019-03-07Merge branch 'sc/pack-redundant'Libravatar Junio C Hamano1-0/+467
Update the implementation of pack-redundant for performance in a repository with many packfiles. * sc/pack-redundant: pack-redundant: consistent sort method pack-redundant: rename pack_list.all_objects pack-redundant: new algorithm to find min packs pack-redundant: delete redundant code pack-redundant: delay creation of unique_objects t5323: test cases for git-pack-redundant
2019-03-07Merge branch 'du/branch-show-current'Libravatar Junio C Hamano1-0/+44
"git branch" learned a new subcommand "--show-current". * du/branch-show-current: branch: introduce --show-current display option
2019-03-07Merge branch 'wh/author-committer-ident-config'Libravatar Junio C Hamano1-0/+74
Four new configuration variables {author,committer}.{name,email} have been introduced to override user.{name,email} in more specific cases. * wh/author-committer-ident-config: config: allow giving separate author and committer idents
2019-03-07Merge branch 'aw/pretty-trailers'Libravatar Junio C Hamano1-0/+117
The %(trailers) formatter in "git log --format=..." now allows to optionally pick trailers selectively by keyword, show only values, etc. * aw/pretty-trailers: pretty: add support for separator option in %(trailers) strbuf: separate callback for strbuf_expand:ing literals pretty: add support for "valueonly" option in %(trailers) pretty: allow showing specific trailers pretty: single return path in %(trailers) handling pretty: allow %(trailers) options with explicit value doc: group pretty-format.txt placeholders descriptions
2019-03-07Merge branch 'nd/diff-parseopt'Libravatar Junio C Hamano1-2/+2
The diff machinery, one of the oldest parts of the system, which long predates the parse-options API, uses fairly long and complex handcrafted option parser. This is being rewritten to use the parse-options API. * nd/diff-parseopt: diff.c: convert --raw diff.c: convert -W|--[no-]function-context diff.c: convert -U|--unified diff.c: convert -u|-p|--patch diff.c: prepare to use parse_options() for parsing diff.h: avoid bit fields in struct diff_flags diff.h: keep forward struct declarations sorted parse-options: allow ll_callback with OPTION_CALLBACK parse-options: avoid magic return codes parse-options: stop abusing 'callback' for lowlevel callbacks parse-options: add OPT_BITOP() parse-options: disable option abbreviation with PARSE_OPT_KEEP_UNKNOWN parse-options: add one-shot mode parse-options.h: remove extern on function prototypes
2019-03-07Merge branch 'tg/checkout-no-overlay'Libravatar Junio C Hamano7-0/+48
"git checkout --no-overlay" can be used to trigger a new mode of checking out paths out of the tree-ish, that allows paths that match the pathspec that are in the current index and working tree and are not in the tree-ish. * tg/checkout-no-overlay: revert "checkout: introduce checkout.overlayMode config" checkout: introduce checkout.overlayMode config checkout: introduce --{,no-}overlay option checkout: factor out mark_cache_entry_for_checkout function checkout: clarify comment read-cache: add invalidate parameter to remove_marked_cache_entries entry: support CE_WT_REMOVE flag in checkout_entry entry: factor out unlink_entry function move worktree tests to t24*
2019-03-03remote-curl: use post_rpc() for protocol v2 alsoLibravatar Jonathan Tan1-1/+32
When transmitting and receiving POSTs for protocol v0 and v1, remote-curl uses post_rpc() (and associated functions), but when doing the same for protocol v2, it uses a separate set of functions (proxy_rpc() and others). Besides duplication of code, this has caused at least one bug: the auth retry mechanism that was implemented in v0/v1 was not implemented in v2. To fix this issue and avoid it in the future, make remote-curl also use post_rpc() when handling protocol v2. Because line lengths are written to the HTTP request in protocol v2 (unlike in protocol v0/v1), this necessitates changes in post_rpc() and some of the functions it uses; perform these changes too. A test has been included to ensure that the code for both the unchunked and chunked variants of the HTTP request is exercised. Note: stateless_connect() has been updated to use the lower-level packet reading functions instead of struct packet_reader. The low-level control is necessary here because we cannot change the destination buffer of struct packet_reader while it is being used; struct packet_buffer has a peeking mechanism which relies on the destination buffer being present in between a peek and a read. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-24diff: reuse diff setup for --no-index caseLibravatar Jeff King1-0/+8
When "--no-index" is in effect (or implied by the arguments), git-diff jumps early to a special code path to perform that diff. This means we miss out on some settings like enabling --ext-diff and --textconv by default. Let's jump to the no-index path _after_ we've done more setup on rev.diffopt. Since some of the options don't affect us (e.g., items related to the index), let's re-order the setup into two blocks (see the in-code comments). Note that we also need to stop re-initializing the diffopt struct in diff_no_index(). This should not be necessary, as it will already have been initialized by cmd_diff() (and there are no other callers). That in turn lets us drop the "repository" argument from diff_no_index (which never made much sense, since the whole point is that you don't need a repository). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22Merge branch 'ab/bsd-fixes'Libravatar Junio C Hamano2-5/+5
Test portability fix. * ab/bsd-fixes: commit-graph tests: fix unportable "dd" invocation tests: fix unportable "\?" and "\+" regex syntax
2019-02-22Merge branch 'ab/workaround-dash-bug-in-test'Libravatar Junio C Hamano1-0/+1
* ab/workaround-dash-bug-in-test: tests: avoid syntax triggering old dash bug
2019-02-22trace2: t/helper/test-trace2, t0210.sh, t0211.sh, t0212.shLibravatar Jeff Hostetler9-0/+1174
Create unit tests for Trace2. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22trace2: create new combined trace facilityLibravatar Jeff Hostetler3-0/+7
Create a new unified tracing facility for git. The eventual intent is to replace the current trace_printf* and trace_performance* routines with a unified set of git_trace2* routines. In addition to the usual printf-style API, trace2 provides higer-level event verbs with fixed-fields allowing structured data to be written. This makes post-processing and analysis easier for external tools. Trace2 defines 3 output targets. These are set using the environment variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT". These may be set to "1" or to an absolute pathname (just like the current GIT_TRACE). * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command summary data. * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE. It extends the output with columns for the command process, thread, repo, absolute and relative elapsed times. It reports events for child process start/stop, thread start/stop, and per-thread function nesting. * GIT_TR2_EVENT is a new structured format. It writes event data as a series of JSON records. Calls to trace2 functions log to any of the 3 output targets enabled without the need to call different trace_printf* or trace_performance* routines. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22commit-graph tests: fix unportable "dd" invocationLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Change an unportable invocation of "dd" with count=0, that wanted to truncate the commit-graph file. In POSIX it is unspecified what happens when count=0 is provided[1]. The NetBSD "dd" behavior differs from GNU (and seemingly other BSDs), which has left this test broken since d2b86fbaa1 ("commit-graph: fix buffer read-overflow", 2019-01-15). Copying from /dev/null would seek/truncate to seek=$zero_pos and stop immediately after that (without being able to copy anything), which is the right way to truncate the file. 1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-21tests: fix unportable "\?" and "\+" regex syntaxLibravatar Ævar Arnfjörð Bjarmason1-4/+4
Fix widely supported but non-POSIX basic regex syntax introduced in [1] and [2]. On GNU, NetBSD and FreeBSD the following works: $ echo xy >f $ grep 'xy\?' f; echo $? xy 0 The same goes for "\+". The "?" and "+" syntax is not in the BRE syntax, just in ERE, but on some implementations it can be invoked by prefixing the meta-operator with "\", but not on OpenBSD: $ uname -a OpenBSD obsd.my.domain 6.2 GENERIC#132 amd64 $ grep --version grep version 0.9 $ grep 'xy\?' f; echo $? 1 Let's fix this by moving to ERE syntax instead, where "?" and "+" are universally supported: $ grep -E 'xy?' f; echo $? xy 0 1. 2ed5c8e174 ("describe: setup working tree for --dirty", 2019-02-03) 2. c801170b0c ("t6120: test for describe with a bare repository", 2019-02-03) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-19Merge branch 'js/test-tool-gen-nuls'Libravatar Junio C Hamano4-7/+24
* js/test-tool-gen-nuls: tests: teach the test-tool to generate NUL bytes and use it
2019-02-19Merge branch 'mk/t5562-no-input-to-too-large-an-input-test'Libravatar Junio C Hamano1-2/+2
* mk/t5562-no-input-to-too-large-an-input-test: t5562: do not depend on /dev/zero Revert "t5562: replace /dev/zero with a pipe from generate_zero_bytes"
2019-02-19t5562: do not reuse output filesLibravatar Max Kirillov1-4/+4
Some expected failures of git-http-backend leaves running its children (receive-pack or upload-pack) which still hold opened descriptors to act.err and with some probability they live long enough to write there their failure messages after next test has already truncated the files. This causes occasional failures of the test script. Avoid the issue by using separated output and error file for each test, apprending the test number to their name. Reported-by: Carlo Arenas <carenas@gmail.com> Helped-by: Carlo Arenas <carenas@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-19tests: teach the test-tool to generate NUL bytes and use itLibravatar Johannes Schindelin4-7/+24
In cc95bc2025 (t5562: replace /dev/zero with a pipe from generate_zero_bytes, 2019-02-09), we replaced usage of /dev/zero (which is not available on NonStop, apparently) by a Perl script snippet to generate NUL bytes. Sadly, it does not seem to work on NonStop, as t5562 reportedly hangs. Worse, this also hangs in the Ubuntu 16.04 agents of the CI builds on Azure Pipelines: for some reason, the Perl script snippet that is run via `generate_zero_bytes` in t5562's 'CONTENT_LENGTH overflow ssite_t' test case tries to write out an infinite amount of NUL bytes unless a broken pipe is encountered, that snippet never encounters the broken pipe, and keeps going until the build times out. Oddly enough, this does not reproduce on the Windows and macOS agents, nor in a local Ubuntu 18.04. This developer tried for a day to figure out the exact circumstances under which this hang happens, to no avail, the details remain a mystery. In the end, though, what counts is that this here change incidentally fixes that hang (maybe also on NonStop?). Even more positively, it gets rid of yet another unnecessary Perl invocation. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-19t5562: do not depend on /dev/zeroLibravatar Max Kirillov1-1/+1
It was reported [1] that NonStop platform does not have /dev/zero. The test uses /dev/zero as a dummy input. Passing case (http-backed failed because of too big input size) should not be reading anything from it. If http-backend would erroneously try to read any data returning EOF probably would be even safer than providing some meaningless data. Replace /dev/zero with /dev/null to avoid issues with platforms which do not have /dev/zero. [1] https://public-inbox.org/git/20190209185930.5256-4-randall.s.becker@rogers.com/ Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-19Revert "t5562: replace /dev/zero with a pipe from generate_zero_bytes"Libravatar Junio C Hamano1-2/+2
Revert cc95bc20 ("t5562: replace /dev/zero with a pipe from generate_zero_bytes", 2019-02-09), as not feeding anything to the command is a better way to test it.
2019-02-14t5304: rename "sha1" variables to "oid"Libravatar Jeff King1-12/+12
Let's make the script less jarring to read in a post-sha1 world by using more hash-agnostic variable names. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-14prune: use bitmaps for reachability traversalLibravatar Jeff King1-0/+11
Pruning generally has to traverse the whole commit graph in order to see which objects are reachable. This is the exact problem that reachability bitmaps were meant to solve, so let's use them (if they're available, of course). Here are timings on git.git: Test HEAD^ HEAD ------------------------------------------------------------------------ 5304.6: prune with bitmaps 3.65(3.56+0.09) 1.01(0.92+0.08) -72.3% And on linux.git: Test HEAD^ HEAD -------------------------------------------------------------------------- 5304.6: prune with bitmaps 35.05(34.79+0.23) 3.00(2.78+0.21) -91.4% The tests show a pretty optimal case, as we'll have just repacked and should have pretty good coverage of all refs with our bitmaps. But that's actually pretty realistic: normally prune is run via "gc" right after repacking. A few notes on the implementation: - the change is actually in reachable.c, so it would improve reachability traversals by "reflog expire --stale-fix", as well. Those aren't performed regularly, though (a normal "git gc" doesn't use --stale-fix), so they're not really worth measuring. There's a low chance of regressing that caller, since the use of bitmaps is totally transparent from the caller's perspective. - The bitmap case could actually get away without creating a "struct object", and instead the caller could just look up each object id in the bitmap result. However, this would be a marginal improvement in runtime, and it would make the callers much more complicated. They'd have to handle both the bitmap and non-bitmap cases separately, and in the case of git-prune, we'd also have to tweak prune_shallow(), which relies on our SEEN flags. - Because we do create real object structs, we go through a few contortions to create ones of the right type. This isn't strictly necessary (lookup_unknown_object() would suffice), but it's more memory efficient to use the correct types, since we already know them. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-14prune: lazily perform reachability traversalLibravatar Jeff King2-0/+36
The general strategy of "git prune" is to do a full reachability walk, then for each loose object see if we found it in our walk. But if we don't have any loose objects, we don't need to do the expensive walk in the first place. This patch postpones that walk until the first time we need to see its results. Note that this is really a specific case of a more general optimization, which is that we could traverse only far enough to find the object under consideration (i.e., stop the traversal when we find it, then pick up again when asked about the next object, etc). That could save us in some instances from having to do a full walk. But it's actually a bit tricky to do with our traversal code, and you'd need to do a full walk anyway if you have even a single unreachable object (which you generally do, if any objects are actually left after running git-repack). So in practice this lazy-load of the full walk catches one easy but common case (i.e., you've just repacked via git-gc, and there's nothing unreachable). The perf script is fairly contrived, but it does show off the improvement: Test HEAD^ HEAD ------------------------------------------------------------------------- 5304.4: prune with no objects 3.66(3.60+0.05) 0.00(0.00+0.00) -100.0% and would let us know if we accidentally regress this optimization. Note also that we need to take special care with prune_shallow(), which relies on us having performed the traversal. So this optimization can only kick in for a non-shallow repository. Since this is easy to get wrong and is not covered by existing tests, let's add an extra test to t5304 that covers this case explicitly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-14Merge branch 'jc/no-grepping-for-strerror-in-tests'Libravatar Junio C Hamano1-1/+1
* jc/no-grepping-for-strerror-in-tests: t1404: do not rely on the exact phrasing of strerror()
2019-02-14Merge branch 'jt/fetch-v2-sideband'Libravatar Junio C Hamano1-0/+1
"git fetch" and "git upload-pack" learned to send all exchange over the sideband channel while talking the v2 protocol. * jt/fetch-v2-sideband: t/lib-httpd: pass GIT_TEST_SIDEBAND_ALL through Apache
2019-02-14t/lib-httpd: pass GIT_TEST_SIDEBAND_ALL through ApacheLibravatar Todd Zullinger1-0/+1
07c3c2aa16 ("tests: define GIT_TEST_SIDEBAND_ALL", 2019-01-16) added GIT_TEST_SIDEBAND_ALL to the apache.conf PassEnv list. Avoid warnings from Apache when the variable is unset, as we do for GIT_VALGRIND* and GIT_TRACE, from f628825481 ("t/lib-httpd: handle running under --valgrind", 2012-07-24) and 89c57ab3f0 ("t: pass GIT_TRACE through Apache", 2015-03-13), respectively. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-14t1404: do not rely on the exact phrasing of strerror()Libravatar Junio C Hamano1-1/+1
Not even in C locale, it is wrong to expect that the exact phrasing "File exists" is used to show EEXIST. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Helped-by: Duy Nguyen <pclouds@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13Merge branch 'ab/rebase-test-fix'Libravatar Junio C Hamano1-3/+6
* ab/rebase-test-fix: rebase: fix regression in rebase.useBuiltin=false test mode
2019-02-13Merge branch 'rb/no-dev-zero-in-test'Libravatar Junio C Hamano3-3/+16
* rb/no-dev-zero-in-test: t5562: replace /dev/zero with a pipe from generate_zero_bytes t5318: replace use of /dev/zero with generate_zero_bytes test-lib-functions.sh: add generate_zero_bytes function
2019-02-13Merge branch 'sg/stress-test'Libravatar Junio C Hamano3-4/+23
Test improvement. * sg/stress-test: test-lib: fix non-portable pattern bracket expressions test-lib: make '--stress' more bisect-friendly
2019-02-13Merge branch 'kd/t0028-octal-del-is-377-not-777'Libravatar Junio C Hamano1-4/+4
Test fix. * kd/t0028-octal-del-is-377-not-777: t0028: fix wrong octal values for BOM in setup
2019-02-13rebase: fix regression in rebase.useBuiltin=false test modeLibravatar Ævar Arnfjörð Bjarmason1-3/+6
Fix a recently introduced regression in c762aada1a ("rebase -x: sanity check command", 2019-01-29) triggered when running the tests with GIT_TEST_REBASE_USE_BUILTIN=false. See 62c23938fa ("tests: add a special setup where rebase.useBuiltin is off", 2018-11-14) for how that test mode works. As discussed on-list[1] it's not worth it to implement the sanity check in the legacy rebase code, we plan to remove it after the 2.21 release. So let's do the bare minimum to make the tests pass under the GIT_TEST_REBASE_USE_BUILTIN=false special setup. 1. https://public-inbox.org/git/xmqqva1nbeno.fsf@gitster-ct.c.googlers.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13tests: avoid syntax triggering old dash bugLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Avoid a bug in dash that's been fixed ever since its ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first released with dash v0.5.7 in July 2011. This failing test was introduced in 5f9674243d ("config: add --expiry-date", 2017-11-18). This fixes 1/2 tests failing on Debian Lenny & Squeeze. The other failure is due to 1b42f45255 ("git-svn: apply "svn.pathnameencoding" before URL encoding", 2016-02-09). The dash bug is triggered by this test because the heredoc contains a command embedded in "$()" with a "{}" block coming right after it. Refactoring the "$()" to e.g. be a variable that was set earlier will also work around it, but let's instead break up the "EOF" and the "{}". An earlier version of this patch[2] mitigated the issue by breaking the "$()" out of the "{}" block, that worked, but just because it broke up the "EOF" and "{}" block. Putting e.g. "echo &&" between the two would also work. 1. https://git.kernel.org/pub/scm/utils/dash/dash.git/ 2. https://public-inbox.org/git/20181127164253.9832-1-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13read-cache.c: fix writing "link" index ext with null base oidLibravatar Nguyễn Thái Ngọc Duy1-0/+18
Since commit 7db118303a (unpack_trees: fix breakage when o->src_index != o->dst_index - 2018-04-23) and changes in merge code to use separate index_state for source and destination, when doing a merge with split index activated, we may run into this line in unpack_trees(): o->result.split_index = init_split_index(&o->result); This is by itself not wrong. But this split index information is not fully populated (and it's only so when move_cache_to_base_index() is called, aka force splitting the index, or loading index_state from a file). Both "base_oid" and "base" in this case remain null. So when writing the main index down, we link to this index with null oid (default value after init_split_index()), which also means "no split index" internally. This triggers an incorrect base index refresh: warning: could not freshen shared index '.../sharedindex.0{40}' This patch makes sure we will not refresh null base_oid (because the file is never there). It also makes sure not to write "link" extension with null base_oid in the first place (no point having it at all). Read code already has protection against null base_oid. There is also another side fix in remove_split_index() that causes a crash when doing "git update-index --no-split-index" when base_oid in the index file is null. In this case we will not load istate->split_index->base but we dereference it anyway and are rewarded with a segfault. This should not happen anymore, but it's still wrong to dereference a potential NULL pointer, especially when we do check for NULL pointer in the next code. Reported-by: Luke Diamand <luke@diamand.org> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13t5562: replace /dev/zero with a pipe from generate_zero_bytesLibravatar Randall S. Becker1-2/+2
To help platforms that lack /dev/zero (e.g. NonStop), replace use of /dev/zero to feed "git http-backend" with a pipe of output from the generate_zero_bytes helper. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13t5318: replace use of /dev/zero with generate_zero_bytesLibravatar Randall S. Becker1-1/+1
There are platforms (e.g. NonStop) that lack /dev/zero; use the generate_zero_bytes helper we just introduced to append stream of NULs at the end of the file. The original, even though it uses "dd seek=... count=..." to make it look like it is overwriting the middle part of an existing file, has truncated the file before this step with another use of "dd", which may make it tricky to see why this rewrite is a correct one. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-12test-lib-functions.sh: add generate_zero_bytes functionLibravatar Randall S. Becker1-0/+13
t5318 and t5562 used /dev/zero, which is not portable. This function provides both a fixed block of NUL bytes and an infinite stream of NULs. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-11utf8: handle systems that don't write BOM for UTF-16Libravatar brian m. carlson1-5/+29
When serializing UTF-16 (and UTF-32), there are three possible ways to write the stream. One can write the data with a BOM in either big-endian or little-endian format, or one can write the data without a BOM in big-endian format. Most systems' iconv implementations choose to write it with a BOM in some endianness, since this is the most foolproof, and it is resistant to misinterpretation on Windows, where UTF-16 and the little-endian serialization are very common. For compatibility with Windows and to avoid accidental misuse there, Git always wants to write UTF-16 with a BOM, and will refuse to read UTF-16 without it. However, musl's iconv implementation writes UTF-16 without a BOM, relying on the user to interpret it as big-endian. This causes t0028 and the related functionality to fail, since Git won't read the file without a BOM. Add a Makefile and #define knob, ICONV_OMITS_BOM, that can be set if the iconv implementation has this behavior. When set, Git will write a BOM manually for UTF-16 and UTF-32 and then force the data to be written in UTF-16BE or UTF-32BE. We choose big-endian behavior here because the tests use the raw "UTF-16" encoding, which will be big-endian when the implementation requires this knob to be set. Update the tests to detect this case and write test data with an added BOM if necessary. Always write the BOM in the tests in big-endian format, since all iconv implementations that omit a BOM must use big-endian serialization according to the Unicode standard. Preserve the existing behavior for systems which do not have this knob enabled, since they may use optimized implementations, including defaulting to the native endianness, which may improve performance. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-11t0028: fix wrong octal values for BOM in setupLibravatar Kevin Daudt1-4/+4
The setup code uses octal values with printf to generate a BOM for UTF-16/32 BE/LE. It specifically uses '\777' to emit a 0xff byte. This relies on the fact that most shells truncate the value above 0o377. Ash however interprets '\777' as '\77' + a literal '7', resulting in an invalid BOM. Fix this by using the proper value of 0xff: '\377'. Signed-off-by: Kevin Daudt <me@ikke.info> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-11test-lib: fix non-portable pattern bracket expressionsLibravatar SZEDER Gábor2-3/+3
Use a '!' character to start a non-matching pattern bracket expression, as specified by POSIX in Shell Command Language section 2.13.1 Patterns Matching a Single Character [1]. I used '^' instead in three places in the previous three commits, to verify that the arguments of the '--stress=' and '--stress-limit=' options and the values of various '*_PORT' environment variables are valid numbers. With certain shells, at least with dash (upstream and in Ubuntu 14.04) and mksh, this led to various undesired behaviors: # error message in case of a valid number $ ~/src/dash/src/dash ./t3903-stash.sh --stress=8 error: --stress=<N> requires the number of jobs to run # not the expected error message $ ~/src/dash/src/dash ./t3903-stash.sh --stress=foo ./t3903-stash.sh: 238: test: Illegal number: foo # no error message at all?! $ mksh ./t3903-stash.sh --stress=foo $ echo $? 0 Some other shells, e.g. Bash (even in posix mode), ksh, dash in Ubuntu 16.04 or later, are apparently happy to accept '^' just as well. [1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13 Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-11test: caution on our version of 'yes'Libravatar Junio C Hamano2-1/+14
During a review of a patch, we noticed that we use our own imitation of 'yes' with the limit of 99 lines. It is very tempting to lift this arbitrary limit, but the limit is there for a reason. Add an in-code comment to prevent future developers from wasting their time. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-08Merge branch 'ld/git-p4-remove-flakey-test'Libravatar Junio C Hamano1-27/+0
A flakey "p4" test has been removed. * ld/git-p4-remove-flakey-test: git-p4: remove ticket expiry test