summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-01-29Merge branch 'it/log-format-source'Libravatar Junio C Hamano2-0/+54
Custom userformat "log --format" learned %S atom that stands for the tip the traversal reached the commit from, i.e. --source. * it/log-format-source: log: add %S option (like --source) to log --format
2019-01-29Merge branch 'jt/upload-pack-deepen-relative-proto-v2'Libravatar Junio C Hamano1-0/+47
"git fetch --deepen=<more>" has been corrected to work over v2 protocol. * jt/upload-pack-deepen-relative-proto-v2: upload-pack: teach deepen-relative in protocol v2 fetch-pack: do not take shallow lock unnecessarily
2019-01-29Merge branch 'ms/http-no-more-failonerror'Libravatar Junio C Hamano2-0/+29
Debugging help for http transport. * ms/http-no-more-failonerror: test: test GIT_CURL_VERBOSE=1 shows an error remote-curl: unset CURLOPT_FAILONERROR remote-curl: define struct for CURLOPT_WRITEFUNCTION http: enable keep_error for HTTP requests http: support file handles for HTTP_KEEP_ERROR
2019-01-29Merge branch 'os/rebase-runs-post-checkout-hook'Libravatar Junio C Hamano1-54/+42
"git rebase" internally runs "checkout" to switch between branches, and the command used to call the post-checkout hook, but the reimplementation stopped doing so, which is getting fixed. * os/rebase-runs-post-checkout-hook: rebase: run post-checkout hook on checkout t5403: simplify by using a single repository
2019-01-29Merge branch 'bc/sha-256'Libravatar Junio C Hamano7-51/+188
Add sha-256 hash and plug it through the code to allow building Git with the "NewHash". * bc/sha-256: hash: add an SHA-256 implementation using OpenSSL sha256: add an SHA-256 implementation using libgcrypt Add a base implementation of SHA-256 support commit-graph: convert to using the_hash_algo t/helper: add a test helper to compute hash speed sha1-file: add a constant for hash block size t: make the sha1 test-tool helper generic t: add basic tests for our SHA-1 implementation cache: make hashcmp and hasheq work with larger hashes hex: introduce functions to print arbitrary hashes sha1-file: provide functions to look up hash algorithms sha1-file: rename algorithm to "sha1"
2019-01-29Merge branch 'sb/submodule-recursive-fetch-gets-the-tip'Libravatar Junio C Hamano2-3/+122
"git fetch --recurse-submodules" may not fetch the necessary commit that is bound to the superproject, which is getting corrected. * sb/submodule-recursive-fetch-gets-the-tip: fetch: ensure submodule objects fetched submodule.c: fetch in submodules git directory instead of in worktree submodule: migrate get_next_submodule to use repository structs repository: repo_submodule_init to take a submodule struct submodule: store OIDs in changed_submodule_names submodule.c: tighten scope of changed_submodule_names struct submodule.c: sort changed_submodule_names before searching it submodule.c: fix indentation sha1-array: provide oid_array_filter
2019-01-29Merge branch 'jt/fetch-pack-v2'Libravatar Junio C Hamano1-7/+15
"git fetch-pack" now can talk the version 2 protocol. * jt/fetch-pack-v2: fetch-pack: support protocol version 2
2019-01-29Merge branch 'jk/proto-v2-hidden-refs-fix'Libravatar Junio C Hamano1-0/+6
The v2 upload-pack protocol implementation failed to honor hidden-ref configuration, which has been corrected. An earlier attempt reverted out of 'next'. * jk/proto-v2-hidden-refs-fix: upload-pack: support hidden refs with protocol v2
2019-01-29Merge branch 'pw/diff-color-moved-ws-fix'Libravatar Junio C Hamano1-3/+96
"git diff --color-moved-ws" updates. * pw/diff-color-moved-ws-fix: diff --color-moved-ws: handle blank lines diff --color-moved-ws: modify allow-indentation-change diff --color-moved-ws: optimize allow-indentation-change diff --color-moved=zebra: be stricter with color alternation diff --color-moved-ws: fix false positives diff --color-moved-ws: demonstrate false positives diff: allow --no-color-moved-ws Use "whitespace" consistently diff: document --no-color-moved
2019-01-29Merge branch 'js/rebase-i-redo-exec'Libravatar Junio C Hamano1-0/+14
"git rebase -i" learned to re-execute a command given with 'exec' to run after it failed the last time. * js/rebase-i-redo-exec: rebase: introduce a shortcut for --reschedule-failed-exec rebase: add a config option to default to --reschedule-failed-exec rebase: introduce --reschedule-failed-exec
2019-01-18Merge branch 'ot/ref-filter-object-info'Libravatar Junio C Hamano1-0/+6
The "--format=<placeholder>" option of for-each-ref, branch and tag learned to show a few more traits of objects that can be learned by the object_info API. * ot/ref-filter-object-info: ref-filter: give uintmax_t to format with %PRIuMAX ref-filter: add docs for new options ref-filter: add tests for deltabase ref-filter: add deltabase option ref-filter: add tests for objectsize:disk ref-filter: add check for negative file size ref-filter: add objectsize:disk option
2019-01-18Merge branch 'sg/stress-test'Libravatar Junio C Hamano9-133/+308
Flaky tests can now be repeatedly run under load with the "--stress" option. * sg/stress-test: test-lib: add the '--stress' option to run a test repeatedly under load test-lib-functions: introduce the 'test_set_port' helper function test-lib: set $TRASH_DIRECTORY earlier test-lib: consolidate naming of test-results paths test-lib: parse command line options earlier test-lib: parse options in a for loop to keep $@ intact test-lib: extract Bash version check for '-x' tracing test-lib: translate SIGTERM and SIGHUP to an exit
2019-01-18Merge branch 'tg/t5570-drop-racy-test'Libravatar Junio C Hamano2-24/+3
An inherently racy test that caused intermittent failures has been removed. * tg/t5570-drop-racy-test: Revert "t/lib-git-daemon: record daemon log" t5570: drop racy test
2019-01-18Merge branch 'so/cherry-pick-always-allow-m1'Libravatar Junio C Hamano3-11/+15
"git cherry-pick -m1" was forbidden when picking a non-merge commit, even though there _is_ parent number 1 for such a commit. This was done to avoid mistakes back when "cherry-pick" was about picking a single commit, but is no longer useful with "cherry-pick" that can pick a range of commits. Now the "-m$num" option is allowed when picking any commit, as long as $num names an existing parent of the commit. Technically this is a backward incompatible change; hopefully nobody is relying on the error-checking behaviour. * so/cherry-pick-always-allow-m1: t3506: validate '-m 1 -ff' is now accepted for non-merge commits t3502: validate '-m 1' argument is now accepted for non-merge commits cherry-pick: do not error on non-merge commits when '-m 1' is specified t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
2019-01-18Merge branch 'nd/worktree-remove-with-uninitialized-submodules'Libravatar Junio C Hamano1-0/+37
"git worktree remove" and "git worktree move" refused to work when there is a submodule involved. This has been loosened to ignore uninitialized submodules. * nd/worktree-remove-with-uninitialized-submodules: worktree: allow to (re)move worktrees with uninitialized submodules
2019-01-18Merge branch 'sg/test-bash-version-fix'Libravatar Junio C Hamano1-2/+2
The test suite tried to see if it is run under bash, but the check itself failed under some other implementations of shell (notably under NetBSD). This has been corrected. * sg/test-bash-version-fix: test-lib: check Bash version for '-x' without using shell arrays
2019-01-18Merge branch 'cy/zsh-completion-SP-in-path'Libravatar Junio C Hamano1-5/+5
With zsh, "git cmd path<TAB>" was completed to "git cmd path name" when the completed path has a special character like SP in it, without any attempt to keep "path name" a single filename. This has been fixed to complete it to "git cmd path\ name" just like Bash completion does. * cy/zsh-completion-SP-in-path: completion: treat results of git ls-tree as file paths zsh: complete unquoted paths with spaces correctly
2019-01-18Merge branch 'sb/submodule-unset-core-worktree-when-worktree-is-lost'Libravatar Junio C Hamano3-3/+14
The core.worktree setting in a submodule repository should not be pointing at a directory when the submodule loses its working tree (e.g. getting deinit'ed), but the code did not properly maintain this invariant. * sb/submodule-unset-core-worktree-when-worktree-is-lost: submodule deinit: unset core.worktree submodule--helper: fix BUG message in ensure_core_worktree submodule: unset core.worktree if no working tree is present submodule update: add regression test with old style setups
2019-01-18Merge branch 'jn/stripspace-wo-repository'Libravatar Junio C Hamano1-3/+9
"git stripspace" should be usable outside a git repository, but under the "-s" or "-c" mode, it didn't. * jn/stripspace-wo-repository: stripspace: allow -s/-c outside git repository
2019-01-18Merge branch 'sb/submodule-fetchjobs-default-to-one'Libravatar Junio C Hamano1-0/+2
"git submodule update" ought to use a single job unless asked, but by mistake used multiple jobs, which has been fixed. * sb/submodule-fetchjobs-default-to-one: submodule update: run at most one fetch job unless otherwise set
2019-01-18Merge branch 'nd/style-opening-brace'Libravatar Junio C Hamano1-1/+2
Code clean-up. * nd/style-opening-brace: style: the opening '{' of a function is in a separate line
2019-01-14Merge branch 'tb/use-common-win32-pathfuncs-on-cygwin'Libravatar Junio C Hamano1-1/+1
Cygwin update. * tb/use-common-win32-pathfuncs-on-cygwin: git clone <url> C:\cygwin\home\USER\repo' is working (again)
2019-01-14Merge branch 'tb/log-G-binary'Libravatar Junio C Hamano1-0/+35
"git log -G<regex>" looked for a hunk in the "git log -p" patch output that contained a string that matches the given pattern. Optimize this code to ignore binary files, which by default will not show any hunk that would match any pattern (unless textconv or the --text option is in effect, that is). * tb/log-G-binary: log -G: ignore binary files
2019-01-14Merge branch 'sb/diff-color-moved-config-option-fixup'Libravatar Junio C Hamano1-0/+18
Minor inconsistency fix. * sb/diff-color-moved-config-option-fixup: diff: align move detection error handling with other options
2019-01-14Merge branch 'hn/highlight-sideband-keywords'Libravatar Junio C Hamano1-0/+2
Lines that begin with a certain keyword that come over the wire, as well as lines that consist only of one of these keywords, ought to be painted in color for easier eyeballing, but the latter was broken ever since the feature was introduced in 2.19, which has been corrected. * hn/highlight-sideband-keywords: sideband: color lines with keyword only
2019-01-14Merge branch 'cb/test-lint-cp-a'Libravatar Junio C Hamano1-0/+1
BSD port update. * cb/test-lint-cp-a: tests: add lint for non portable cp -a
2019-01-14Merge branch 'cb/t5004-empty-tar-archive-fix'Libravatar Junio C Hamano1-9/+8
BSD port update. * cb/t5004-empty-tar-archive-fix: t5004: avoid using tar for empty packages
2019-01-14Merge branch 'hb/t0061-dot-in-path-fix'Libravatar Junio C Hamano1-1/+9
Test update. * hb/t0061-dot-in-path-fix: t0061: do not fail test if '.' is part of $PATH
2019-01-14Merge branch 'nd/checkout-noisy'Libravatar Junio C Hamano1-2/+2
"git checkout [<tree-ish>] path..." learned to report the number of paths that have been checked out of the index or the tree-ish, which gives it the same degree of noisy-ness as the case in which the command checks out a branch. * nd/checkout-noisy: t0027: squelch checkout path run outside test_expect_* block checkout: print something when checking out paths
2019-01-14Merge branch 'nd/attr-pathspec-in-tree-walk'Libravatar Junio C Hamano1-1/+57
The traversal over tree objects has learned to honor ":(attr:label)" pathspec match, which has been implemented only for enumerating paths on the filesystem. * nd/attr-pathspec-in-tree-walk: tree-walk: support :(attr) matching dir.c: move, rename and export match_attrs() pathspec.h: clean up "extern" in function declarations tree-walk.c: make tree_entry_interesting() take an index tree.c: make read_tree*() take 'struct repository *'
2019-01-14Merge branch 'md/list-lazy-objects-fix'Libravatar Junio C Hamano1-2/+14
"git rev-list --exclude-promisor-objects" had to take an object that does not exist locally (and is lazily available) from the command line without barfing, but the code dereferenced NULL. * md/list-lazy-objects-fix: list-objects.c: don't segfault for missing cmdline objects
2019-01-11log: add %S option (like --source) to log --formatLibravatar Issac Trotts2-0/+54
Make it possible to write for example git log --format="%H,%S" where the %S at the end is a new placeholder that prints out the ref (tag/branch) for each commit. Using %d might seem like an alternative but it only shows the ref for the last commit in the branch. Signed-off-by: Issac Trotts <issactrotts@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-10test: test GIT_CURL_VERBOSE=1 shows an errorLibravatar Masaya Suzuki2-0/+29
This tests GIT_CURL_VERBOSE shows an error when an URL returns 500. This exercises the code in remote_curl. Signed-off-by: Masaya Suzuki <masayasuzuki@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-10upload-pack: teach deepen-relative in protocol v2Libravatar Jonathan Tan1-0/+29
Commit 685fbd3291 ("fetch-pack: perform a fetch using v2", 2018-03-15) attempted to teach Git deepen-relative in protocol v2 (among other things), but it didn't work: (1) fetch-pack.c needs to emit "deepen-relative". (2) upload-pack.c needs to ensure that the correct deepen_relative variable is passed to deepen() (there are two - the static variable and the one in struct upload_pack_data). (3) Before deepen() computes the list of reachable shallows, it first needs to mark all "our" refs as OUR_REF. v2 currently does not do this, because unlike v0, it is not needed otherwise. Fix all this and include a test demonstrating that it works now. For (2), the static variable deepen_relative is also eliminated, removing a source of confusion. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Reviewed-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-10fetch-pack: do not take shallow lock unnecessarilyLibravatar Jonathan Tan1-0/+18
When fetching using protocol v2, the remote may send a "shallow-info" section if the client is shallow. If so, Git as the client currently takes the shallow file lock, even if the "shallow-info" section is empty. This is not a problem except that Git does not support taking the shallow file lock after modifying the shallow file, because is_repository_shallow() stores information that is never cleared. And this take-after-modify occurs when Git does a tag-following fetch from a shallow repository on a transport that does not support tag following (since in this case, 2 fetches are performed). To solve this issue, take the shallow file lock (and perform all other shallow processing) only if the "shallow-info" section is non-empty; otherwise, behave as if it were empty. A full solution (probably, ensuring that any action of committing shallow file locks also includes clearing the information stored by is_repository_shallow()) would solve the issue without need for this patch, but this patch is independently useful (as an optimization to prevent writing a file in an unnecessary case), hence why I wrote it. I have included a NEEDSWORK outlining the full solution. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-10fetch-pack: support protocol version 2Libravatar Jonathan Tan1-7/+15
When the scaffolding for protocol version 2 was initially added in 8f6982b4e1 ("protocol: introduce enum protocol_version value protocol_v2", 2018-03-14). As seen in: git log -p -G'support for protocol v2 not implemented yet' --full-diff --reverse v2.17.0..v2.20.0 Many of those scaffolding "die" placeholders were removed, but we hadn't gotten around to fetch-pack yet. The test here for "fetch refs from cmdline" is very minimal. There's much better coverage when running the entire test suite under the WIP GIT_TEST_PROTOCOL_VERSION=2 mode[1], we should ideally have better coverage without needing to invoke a special test mode. 1. https://public-inbox.org/git/20181213155817.27666-1-avarab@gmail.com/ Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-10upload-pack: support hidden refs with protocol v2Libravatar Jeff King1-0/+6
In the v2 protocol, upload-pack's advertisement has been moved to the "ls-refs" command. That command does not respect hidden-ref config (like transfer.hiderefs) at all, and advertises everything. While there are some features that are not supported in v2 (e.g., v2 always allows fetching any sha1 without respect to advertisements), the lack of this feature is not documented and is likely just a bug. Let's make it work, as otherwise upgrading a server to a v2-capable git will start exposing these refs that the repository admin has asked to remain hidden. Note that we assume we're operating on behalf of a fetch here, since that's the only thing implemented in v2 at this point. See the in-code comment. We'll have to figure out how this works when the v2 push protocol is designed (both here in ls-refs, but also rejecting updates to hidden refs). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-10diff --color-moved-ws: handle blank linesLibravatar Phillip Wood1-4/+37
When using --color-moved-ws=allow-indentation-change allow lines with the same indentation change to be grouped across blank lines. For now this only works if the blank lines have been moved as well, not for blocks that have just had their indentation changed. This completes the changes to the implementation of --color-moved=allow-indentation-change. Running git diff --color-moved=allow-indentation-change v2.18.0 v2.19.0 now takes 5.0s. This is a saving of 41% from 8.5s for the optimized version of the previous implementation and 66% from the original which took 14.6s. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-10diff --color-moved-ws: modify allow-indentation-changeLibravatar Phillip Wood1-0/+56
Currently diff --color-moved-ws=allow-indentation-change does not support indentation that contains a mix of tabs and spaces. For example in commit 546f70f377 ("convert.h: drop 'extern' from function declaration", 2018-06-30) the function parameters in the following lines are not colored as moved [1]. -extern int stream_filter(struct stream_filter *, - const char *input, size_t *isize_p, - char *output, size_t *osize_p); +int stream_filter(struct stream_filter *, + const char *input, size_t *isize_p, + char *output, size_t *osize_p); This commit changes the way the indentation is handled to track the visual size of the indentation rather than the characters in the indentation. This has the benefit that any whitespace errors do not interfer with the move detection (the whitespace errors will still be highlighted according to --ws-error-highlight). During the discussion of this feature there were concerns about the correct detection of indentation for python. However those concerns apply whether or not we're detecting moved lines so no attempt is made to determine if the indentation is 'pythonic'. [1] Note that before the commit to fix the erroneous coloring of moved lines each line was colored as a different block, since that commit they are uncolored. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-10diff --color-moved=zebra: be stricter with color alternationLibravatar Phillip Wood1-3/+3
Currently when using --color-moved=zebra the color of moved blocks depends on the number of lines separating them. This means that adding an odd number of unmoved lines between blocks that are already separated by one or more unmoved lines will change the color of subsequent moved blocks. This does not make much sense as the blocks were already separated by unmoved lines and causes problems when adding lines to test cases. Fix this by only using the alternate colors for adjacent moved blocks. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-10diff --color-moved-ws: demonstrate false positivesLibravatar Phillip Wood1-2/+6
'diff --color-moved-ws=allow-indentation-change' can highlight lines that have internal whitespace changes rather than indentation changes. For example in commit 1a07e59c3e ("Update messages in preparation for i18n", 2018-07-21) the lines - die (_("must end with a color")); + die(_("must end with a color")); are highlighted as moved when they should not be. Modify an existing test to show the problem that will be fixed in the next commit. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07worktree: allow to (re)move worktrees with uninitialized submodulesLibravatar Nguyễn Thái Ngọc Duy1-0/+37
Uninitialized submodules have nothing valueable for us to be worried about. They are just SHA-1. Let "worktree remove" and "worktree move" continue in this case so that people can still use multiple worktrees on repos with optional submodules that are never populated, like sha1collisiondetection in git.git when checked out by doc-diff script. Note that for "worktree remove", it is possible that a user initializes a submodule (*), makes some commits (but not push), then deinitializes it. At that point, the submodule is unpopulated, but the precious new commits are still in $GIT_COMMON_DIR/worktrees/<worktree>/modules/<submodule> directory and we should not allow removing the worktree or we lose those commits forever. The new directory check is added to prevent this. (*) yes they are screwed anyway by doing this since "git submodule" would add submodule.* in $GIT_COMMON_DIR/config, which is shared across multiple worktrees. But it does not mean we let them be screwed even more. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07test-lib: add the '--stress' option to run a test repeatedly under loadLibravatar SZEDER Gábor3-5/+130
Unfortunately, we have a few flaky tests, whose failures tend to be hard to reproduce. We've found that the best we can do to reproduce such a failure is to run the test script repeatedly while the machine is under load, and wait in the hope that the load creates enough variance in the timing of the test's commands that a failure is evenually triggered. I have a command to do that, and I noticed that two other contributors have rolled their own scripts to do the same, all choosing slightly different approaches. To help reproduce failures in flaky tests, introduce the '--stress' option to run a test script repeatedly in multiple parallel jobs until one of them fails, thereby using the test script itself to increase the load on the machine. The number of parallel jobs is determined by, in order of precedence: the number specified as '--stress=<N>', or the value of the GIT_TEST_STRESS_LOAD environment variable, or twice the number of available processors (as reported by the 'getconf' utility), or 8. Make '--stress' imply '--verbose -x --immediate' to get the most information about rare failures; there is really no point in spending all the extra effort to reproduce such a failure, and then not know which command failed and why. To prevent the several parallel invocations of the same test from interfering with each other: - Include the parallel job's number in the name of the trash directory and the various output files under 't/test-results/' as a '.stress-<Nr>' suffix. - Add the parallel job's number to the port number specified by the user or to the test number, so even tests involving daemons listening on a TCP socket can be stressed. - Redirect each parallel test run's verbose output to 't/test-results/$TEST_NAME.stress-<nr>.out', because dumping the output of several parallel running tests to the terminal would create a big ugly mess. For convenience, print the output of the failed test job at the end, and rename its trash directory to end with the '.stress-failed' suffix, so it's easy to find in a predictable path (OTOH, all absolute paths recorded in the trash directory become invalid; we'll see whether this causes any issues in practice). If, in an unlikely case, more than one jobs were to fail nearly at the same time, then print the output of all failed jobs, and rename the trash directory of only the last one (i.e. with the highest job number), as it is the trash directory of the test whose output will be at the bottom of the user's terminal. Based on Jeff King's 'stress' script. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07test-lib-functions: introduce the 'test_set_port' helper functionLibravatar SZEDER Gábor7-13/+41
Several test scripts run daemons like 'git-daemon' or Apache, and communicate with them through TCP sockets. To have unique ports where these daemons are accessible, the ports are usually the number of the corresponding test scripts, unless the user overrides them via environment variables, and thus all those tests and test libs contain more or less the same bit of one-liner boilerplate code to find out the port. The last patch in this series will make this a bit more complicated. Factor out finding the port for a daemon into the common helper function 'test_set_port' to avoid repeating ourselves. Take special care of test scripts with "low" numbers: - Test numbers below 1024 would result in a port that's only usable as root, so set their port to '10000 + test-nr' to make sure it doesn't interfere with other tests in the test suite. This makes the hardcoded port number in 't0410-partial-clone.sh' unnecessary, remove it. - The shell's arithmetic evaluation interprets numbers with leading zeros as octal values, which means that test number below 1000 and containing the digits 8 or 9 will trigger an error. Remove all leading zeros from the test numbers to prevent this. Note that the 'git p4' tests are unlike the other tests involving daemons in that: - 'lib-git-p4.sh' doesn't use the test's number for unique port as is, but does a bit of additional arithmetic on top [1]. - The port is not overridable via an environment variable. With this patch even 'git p4' tests will use the test's number as default port, and it will be overridable via the P4DPORT environment variable. [1] Commit fc00233071 (git-p4 tests: refactor and cleanup, 2011-08-22) introduced that "unusual" unique port computation without explaining why it was necessary (as opposed to simply using the test number as is). It seems to be just unnecessary complication, and in any case that commit came way before the "test nr as unique port" got "standardized" for other daemons in commits c44132fcf3 (tests: auto-set git-daemon port, 2014-02-10), 3bb486e439 (tests: auto-set LIB_HTTPD_PORT from test name, 2014-02-10), and bf9d7df950 (t/lib-git-svn.sh: improve svnserve tests with parallel make test, 2017-12-01). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07test-lib: set $TRASH_DIRECTORY earlierLibravatar SZEDER Gábor1-6/+6
A later patch in this series will need to know the path to the trash directory early in 'test-lib.sh', but $TRASH_DIRECTORY is set much later. Set $TRASH_DIRECTORY earlier, where the other test-specific path variables are set. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07test-lib: consolidate naming of test-results pathsLibravatar SZEDER Gábor1-11/+11
There are two places where we strip off any leading path components and the '.sh' suffix from the test script's pathname, and there are four places where we construct the name of the 't/test-results' directory or the name of various test-specific files in there. The last patch in this series will add even more. Factor these out into helper variables to avoid repeating ourselves. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07test-lib: parse command line options earlierLibravatar SZEDER Gábor1-109/+124
'test-lib.sh' looks for the presence of certain options like '--tee' and '--verbose-log', so it can execute the test script again to save its standard output and error. It looks for '--valgrind' as well, to set up some Valgrind-specific stuff. These all happen before the actual option parsing loop, and the conditions looking for these options look a bit odd, too. They are not completely correct, either, because in a bogus invocation like './t1234-foo.sh -r --tee' they recognize '--tee', although it should be handled as the required argument of the '-r' option. This patch series will add two more options to look out for early, and, in addition, will have to extract these options' stuck arguments (i.e. '--opt=arg') as well. So let's move the option parsing loop and the couple of related conditions following it earlier in 'test-lib.sh', before the place where the test script is executed again for '--tee' and its friends. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07test-lib: parse options in a for loop to keep $@ intactLibravatar SZEDER Gábor1-36/+42
'test-lib.sh' looks for the presence of certain options like '--tee' and '--verbose-log', so it can execute the test script again to save its standard output and error, and to do so it needs the original command line options the test was invoked with. The next patch is about to move the option parsing loop earlier in 'test-lib.sh', but it is implemented using 'shift' in a while loop, effecively destroying "$@" by the end of the option parsing. Not good. As a preparatory step, turn that option parsing loop into a 'for opt in "$@"' loop to preserve "$@" intact while iterating over the options, and taking extra care to handle the '-r' option's required argument (or the lack thereof). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07test-lib: extract Bash version check for '-x' tracingLibravatar SZEDER Gábor1-18/+19
One of our test scripts, 't1510-repo-setup.sh' [1], still can't be reliably run with '-x' tracing enabled, unless it's executed with a Bash version supporting BASH_XTRACEFD (since v4.1). We have a lengthy condition to check the version of the shell running the test script, and disable tracing if it's not executed with a suitable Bash version [2]. Move this check out from the option parsing loop, so other options can imply '-x' by setting 'trace=t', without missing this Bash version check. [1] 5827506928 (t1510-repo-setup: mark as untraceable with '-x', 2018-02-24) [2] 5fc98e79fc (t: add means to disable '-x' tracing for individual test scripts, 2018-02-24) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07t3506: validate '-m 1 -ff' is now accepted for non-merge commitsLibravatar Sergey Organov1-3/+3
Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>