summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-06-13add -p: fix checkout -p with pathological contextLibravatar Phillip Wood1-0/+8
Commit fecc6f3a68 ("add -p: adjust offsets of subsequent hunks when one is skipped", 2018-03-01) fixed adding hunks in the correct place when a previous hunk has been skipped. However it did not address patches that are applied in reverse. In that case we need to adjust the pre-image offset so that when apply reverses the patch the post-image offset is adjusted correctly. We subtract rather than add the delta as the patch is reversed (the easiest way to think about it is to consider a hunk of deletions that is skipped - in that case we want to reduce offset so we need to subtract). Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-11add -p: fix counting empty context lines in edited patchesLibravatar Phillip Wood1-0/+43
recount_edited_hunk() introduced in commit 2b8ea7f3c7 ("add -p: calculate offset delta for edited patches", 2018-03-05) required all context lines to start with a space, empty lines are not counted. This was intended to avoid any recounting problems if the user had introduced empty lines at the end when editing the patch. However this introduced a regression into 'git add -p' as it seems it is common for editors to strip the trailing whitespace from empty context lines when patches are edited thereby introducing empty lines that should be counted. 'git apply' knows how to deal with such empty lines and POSIX states that whether or not there is an space on an empty context line is implementation defined [1]. Fix the regression by counting lines that consist solely of a newline as well as lines starting with a space as context lines and add a test to prevent future regressions. [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/diff.html Reported-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net> Reported-by: Oliver Joseph Ash <oliverjash@gmail.com> Reported-by: Jeff Felchner <jfelchner1@gmail.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05add -p: fix counting when splitting and coalescingLibravatar Phillip Wood1-8/+23
When a file has no trailing new line at the end diff records this by appending "\ No newline at end of file" below the last line of the file. This line should not be counted in the hunk header. Fix the splitting and coalescing code to count files without a trailing new line properly and change one of the tests to test splitting without a trailing new line. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05add -p: calculate offset delta for edited patchesLibravatar Phillip Wood1-1/+1
Recount the number of preimage and postimage lines in a hunk after it has been edited so any change in the number of insertions or deletions can be used to adjust the offsets of subsequent hunks. If an edited hunk is subsequently split then the offset correction will be lost. It would be possible to fix this if it is a problem, however the code here is still an improvement on the status quo for the common case where an edited hunk is applied without being split. This is also a necessary step to removing '--recount' and '--allow-overlap' from the invocation of 'git apply'. Before '--recount' can be removed the splitting and coalescing counting needs to be fixed to handle a missing newline at the end of a file. In order to remove '--allow-overlap' there needs to be i) some way of verifying the offset data in the edited hunk (probably by correlating the preimage (or postimage if the patch is going to be applied in reverse) lines of the edited and unedited versions to see if they are offset or if any leading/trailing context lines have been removed) and ii) a way of dealing with edited hunks that change context lines that are shared with neighbouring hunks. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-01add -p: adjust offsets of subsequent hunks when one is skippedLibravatar Phillip Wood1-1/+1
Since commit 8cbd431082 ("git-add--interactive: replace hunk recounting with apply --recount", 2008-7-2) if a hunk is skipped then we rely on the context lines to apply subsequent hunks in the right place. While this works most of the time it is possible for hunks to end up being applied in the wrong place. To fix this adjust the offset of subsequent hunks to correct for any change in the number of insertions or deletions due to the skipped hunk. The change in offset due to edited hunks that have the number of insertions or deletions changed is ignored here, it will be fixed in the next commit. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-01t3701: add failing test for pathological context linesLibravatar Phillip Wood1-0/+30
When a hunk is skipped by add -i the offsets of subsequent hunks are not adjusted to account for any missing insertions due to the skipped hunk. Most of the time this does not matter as apply uses the context lines to apply the subsequent hunks in the correct place, however in pathological cases the context lines will match at the now incorrect offset and the hunk will be applied in the wrong place. The offsets of hunks following an edited hunk that has had the number of insertions or deletions changed also need to be updated in the same way. Add failing tests to demonstrate this. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-01t3701: don't hard code sha1 hash valuesLibravatar Phillip Wood1-10/+23
Use a filter when comparing diffs to fix the value of non-zero hashes in diff index lines so we're not hard coding sha1 hash values in the expected output. This makes it easier to change the expected output if a test is edited as we don't need to worry about the exact hash value and means the tests will work when the hash algorithm is transitioned away from sha1. Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-20t3701: use test_write_lines and write_scriptLibravatar Phillip Wood1-28/+5
Simplify things slightly by using the above helpers. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-20t3701: indent here documentsLibravatar Phillip Wood1-87/+87
Indent here documents in line with the current style for tests. While at it, quote the end marker of here-docs that do not use variable interpolation. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-21Merge branch 'bc/hash-algo' into maintLibravatar Junio C Hamano1-0/+17
* bc/hash-algo: t5601-clone: test case-conflicting files on case-insensitive filesystem repository: pre-initialize hash algo pointer
2018-01-21t5601-clone: test case-conflicting files on case-insensitive filesystemLibravatar Eric Sunshine1-0/+17
A recently introduced regression caused a segfault at clone time on case-insensitive filesystems when filenames differing only in case are present. This bug has already been fixed (repository: pre-initialize hash algo pointer, 2018-01-18), but it's not the first time similar problems have arisen. Therefore, introduce a test to catch this case and protect against future regressions. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-11Merge branch 'js/test-with-ws-in-path'Libravatar Junio C Hamano1-4/+4
Hot fix to a test. * js/test-with-ws-in-path: t3900: add some more quotes
2018-01-10t3900: add some more quotesLibravatar Beat Bolli1-4/+4
In 89a70b80 ("t0302 & t3900: add forgotten quotes", 2018-01-03), quotes were added to protect against spaces in $HOME. In the test_when_finished command, two files are deleted which must be quoted individually. [jc: with \$HOME in the test_when_finished command quoted, as pointed out by j6t]. Signed-off-by: Beat Bolli <dev+git@drbeat.li> Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-10Merge branch 'js/perl-path-workaround-in-tests'Libravatar Junio C Hamano1-1/+16
* js/perl-path-workaround-in-tests: mingw: handle GITPERLLIB in t0021 in a Windows-compatible way
2018-01-10Merge branch 'ew/empty-merge-with-dirty-index'Libravatar Junio C Hamano1-0/+50
"git merge -s recursive" did not correctly abort when the index is dirty, if the merged tree happened to be the same as the current HEAD, which has been fixed. * ew/empty-merge-with-dirty-index: merge-recursive: do not look at the index during recursive merge
2018-01-10Merge branch 'js/fix-merge-arg-quoting-in-rebase-p'Libravatar Junio C Hamano1-0/+14
"git rebase -p -X<option>" did not propagate the option properly down to underlying merge strategy backend. * js/fix-merge-arg-quoting-in-rebase-p: rebase -p: fix quoting when calling `git merge`
2018-01-10mingw: handle GITPERLLIB in t0021 in a Windows-compatible wayLibravatar Johannes Schindelin1-1/+16
Git's assumption that all path lists are colon-separated is not only wrong on Windows, it is not even an assumption that is compatible with POSIX. In the interest of time, let's not try to fix this properly but simply work around the obvious breakage on Windows, where the MSYS2 Bash used by Git for Windows to interpret the Git's Unix shell scripts will automagically convert path lists in the environment to semicolon-separated lists of Windows paths (with drive letter and the corresponding colon and all that jazz). In other words, we simply look whether there is a semicolon in GITPERLLIB and split by semicolons if found instead of colons. This is not fool-proof, of course, as the path list could consist of a single path. But that is not the case in Git for Windows' test suite, there are always two paths in GITPERLLIB. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-09Merge branch 'bw/protocol-v1'Libravatar Junio C Hamano1-6/+4
Test fix for a topic already in 'master'. * bw/protocol-v1: http: fix v1 protocol tests with apache httpd < 2.4
2018-01-09Merge branch 'js/test-with-ws-in-path'Libravatar Junio C Hamano5-10/+10
Test fixes. * js/test-with-ws-in-path: t0302 & t3900: add forgotten quotes Allow the test suite to pass in a directory whose name contains spaces
2018-01-09Merge branch 'ew/empty-merge-with-dirty-index-maint' into ↵Libravatar Junio C Hamano1-0/+50
ew/empty-merge-with-dirty-index * ew/empty-merge-with-dirty-index-maint: merge-recursive: do not look at the index during recursive merge
2018-01-09merge-recursive: do not look at the index during recursive mergeLibravatar Junio C Hamano1-0/+50
When merging another branch into ours, if their tree is the same as the common ancestor's, we can declare that our tree represents the result of three-way merge. In such a case, the recursive merge backend incorrectly used to create a commit out of our index, even when the index has changes. A recent fix attempted to prevent this by adding a comparison between "our" tree and the index, but forgot that this check must be restricted only to the outermost merge. Inner merges performed by the recursive backend across merge bases are by definition made from scratch without having any local changes added to the index. The call to index_has_changes() during an inner merge is working on the index that has no relation to the merge being performed, preventing legitimate merges from getting carried out. Fix it by limiting the check to the outermost merge. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05Merge branch 'jh/memihash-opt'Libravatar Junio C Hamano1-1/+1
Squelch compiler warning. * jh/memihash-opt: t/helper/test-lazy-name-hash: fix compilation
2018-01-05Merge branch 'tb/test-lint-wc-l'Libravatar Junio C Hamano1-0/+1
Test update. * tb/test-lint-wc-l: check-non-portable-shell.pl: `wc -l` may have leading WS
2018-01-05Merge branch 'ld/p4-multiple-shelves'Libravatar Junio C Hamano1-10/+14
"git p4" update. * ld/p4-multiple-shelves: git-p4: update multiple shelved change lists
2018-01-05Merge branch 'ew/empty-merge-with-dirty-index'Libravatar Junio C Hamano1-5/+21
"git merge -s recursive" did not correctly abort when the index is dirty, if the merged tree happened to be the same as the current HEAD, which has been fixed. * ew/empty-merge-with-dirty-index: merge-recursive: avoid incorporating uncommitted changes in a merge move index_has_changes() from builtin/am.c to merge.c for reuse t6044: recursive can silently incorporate dirty changes in a merge
2018-01-05Merge branch 'jk/test-suite-tracing'Libravatar Junio C Hamano3-18/+40
Assorted fixes around running tests with "-x" tracing option. * jk/test-suite-tracing: t/Makefile: introduce TEST_SHELL_PATH test-lib: make "-x" work with "--verbose-log" t5615: avoid re-using descriptor 4 test-lib: silence "-x" cleanup under bash
2018-01-05rebase -p: fix quoting when calling `git merge`Libravatar Johannes Schindelin1-0/+14
It has been reported that strategy arguments are not passed to `git merge` correctly when rebasing interactively, preserving merges. The reason is that the strategy arguments are already quoted, and then quoted again. This fixes https://github.com/git-for-windows/git/issues/1321 Original-patch-by: Kim Gybels <kgybels@infogroep.be> Also-reported-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-04http: fix v1 protocol tests with apache httpd < 2.4Libravatar Todd Zullinger1-6/+4
The apache config used by tests was updated to use the SetEnvIf directive to set the Git-Protocol header in 19113a26b6 ("http: tell server that the client understands v1", 2017-10-16). Setting the Git-Protocol header is restricted to httpd >= 2.4, but mod_setenvif and the SetEnvIf directive work with lower versions, at least as far back as 2.0, according to the httpd documentation: https://httpd.apache.org/docs/2.0/mod/mod_setenvif.html Drop the restriction. Tested with httpd 2.2 and 2.4. Signed-off-by: Todd Zullinger <tmz@pobox.com> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-03t0302 & t3900: add forgotten quotesLibravatar Johannes Schindelin2-5/+5
When cleaning up files in the $HOME directory, it really makes sense to quote the path, especially in Git's test suite, where the HOME directory is *guaranteed* to contain spaces in its name. It would appear that those two tests pass even without cleaning up the files, but really more by pure chance than by design (the cleanup seems not actually to be necessary). However, if anybody would have a left-over `trash/` directory in Git's `t/` directory, these tests would fail, because they would all of a sudden try to delete that directory, but without the `-r` (recursive) flag. That is how this issue was found. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-03Allow the test suite to pass in a directory whose name contains spacesLibravatar Johannes Schindelin3-5/+5
It is totally legitimate to clone Git's source code anywhere, including into, say, directories whose name (or the name of its absolute path) contains spaces. However, a couple of tests failed to anticipate this, for lack of quoting (or in one instance, for failure to expect more than one space in the absolute path of the TEST_DIRECTORY). This can be easily verified by calling these commands in your current clone: git clone . with\ spaces cd with\ spaces make -j15 test Let's fix this. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-28Merge branch 'sb/describe-blob'Libravatar Junio C Hamano2-1/+112
"git describe" was taught to dig trees deeper to find a <commit-ish>:<path> that refers to a given blob object. * sb/describe-blob: builtin/describe.c: describe a blob builtin/describe.c: factor out describe_commit builtin/describe.c: print debug statements earlier builtin/describe.c: rename `oid` to avoid variable shadowing revision.h: introduce blob/tree walking in order of the commits list-objects.c: factor out traverse_trees_and_blobs t6120: fix typo in test name
2017-12-28Merge branch 'hi/merge-verify-sig-config'Libravatar Junio C Hamano2-0/+126
"git merge" learned to pay attention to merge.verifySignatures configuration variable and pretend as if '--verify-signatures' option was given from the command line. * hi/merge-verify-sig-config: t5573, t7612: clean up after unexpected success of 'pull' and 'merge' t: add tests for pull --verify-signatures merge: add config option for verifySignatures
2017-12-28Merge branch 'bp/fsmonitor'Libravatar Junio C Hamano1-2/+1
Test fix. * bp/fsmonitor: p7519: improve check for prerequisite WATCHMAN
2017-12-28Merge branch 'tz/lib-git-svn-svnserve-tests'Libravatar Junio C Hamano1-11/+13
* tz/lib-git-svn-svnserve-tests: t/lib-git-svn.sh: improve svnserve tests with parallel make test t/lib-git-svn: cleanup inconsistent tab/space usage
2017-12-28Merge branch 'ew/svn-crlf'Libravatar Junio C Hamano1-0/+27
"git svn" has been updated to strip CRs in the commit messages, as recent versions of Subversion rejects them. * ew/svn-crlf: git-svn: convert CRLF to LF in commit message to SVN
2017-12-28Merge branch 'cc/skip-to-optional-val'Libravatar Junio C Hamano1-48/+62
Introduce a helper to simplify code to parse a common pattern that expects either "--key" or "--key=<something>". * cc/skip-to-optional-val: t4045: reindent to make helpers readable diff: add tests for --relative without optional prefix value diff: use skip_to_optional_arg_default() in parsing --relative diff: use skip_to_optional_arg_default() diff: use skip_to_optional_arg() index-pack: use skip_to_optional_arg() git-compat-util: introduce skip_to_optional_arg()
2017-12-27Merge branch 'sb/test-helper-excludes'Libravatar Junio C Hamano1-41/+5
Simplify the ignore rules for t/helper directory. * sb/test-helper-excludes: t/helper: ignore everything but sources
2017-12-27Merge branch 'es/clone-shared-worktree'Libravatar Junio C Hamano1-0/+6
"git clone --shared" to borrow from a (secondary) worktree did not work, even though "git clone --local" did. Both are now accepted. * es/clone-shared-worktree: clone: support 'clone --shared' from a worktree
2017-12-27Merge branch 'jt/decorate-api'Libravatar Junio C Hamano3-0/+85
A few structures and variables that are implementation details of the decorate API have been renamed and then the API got documented better. * jt/decorate-api: decorate: clean up and document API
2017-12-27Merge branch 'es/worktree-checkout-hook'Libravatar Junio C Hamano1-0/+29
"git worktree add" learned to run the post-checkout hook, just like "git checkout" does, after the initial checkout. * es/worktree-checkout-hook: worktree: invoke post-checkout hook (unless --no-checkout)
2017-12-27Merge branch 'lb/rebase-i-short-command-names'Libravatar Junio C Hamano1-0/+22
With a configuration variable rebase.abbreviateCommands set, "git rebase -i" produces the todo list with a single-letter command names. * lb/rebase-i-short-command-names: sequencer.c: drop 'const' from function return type t3404: add test case for abbreviated commands rebase -i: learn to abbreviate command names rebase -i -x: add exec commands via the rebase--helper rebase -i: update functions to use a flags parameter rebase -i: replace reference to sha1 with oid rebase -i: refactor transform_todo_ids rebase -i: set commit to null in exec commands Documentation: use preferred name for the 'todo list' script Documentation: move rebase.* configs to new file
2017-12-27Merge branch 'tb/check-crlf-for-safe-crlf'Libravatar Junio C Hamano1-5/+72
The "safe crlf" check incorrectly triggered for contents that does not use CRLF as line endings, which has been corrected. * tb/check-crlf-for-safe-crlf: t0027: Adapt the new MIX tests to Windows convert: tighten the safe autocrlf handling
2017-12-27Merge branch 'jh/object-filtering'Libravatar Junio C Hamano2-0/+600
In preparation for implementing narrow/partial clone, the object walking machinery has been taught a way to tell it to "filter" some objects from enumeration. * jh/object-filtering: rev-list: support --no-filter argument list-objects-filter-options: support --no-filter list-objects-filter-options: fix 'keword' typo in comment pack-objects: add list-objects filtering rev-list: add list-objects filtering support list-objects: filter objects in traverse_commit_list oidset: add iterator methods to oidset oidmap: add oidmap iterator methods dir: allow exclusions from blob in addition to file
2017-12-22git-p4: update multiple shelved change listsLibravatar Luke Diamand1-10/+14
--update-shelve can now be specified multiple times on the command-line, to update multiple shelved changelists in a single submit. This then means that a git patch series can be mirrored to a sequence of shelved changelists, and (relatively easily) kept in sync as changes are made in git. Note that Perforce does not really support overlapping shelved changelists where one change touches the files modified by another. Trying to do this will result in merge conflicts. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22check-non-portable-shell.pl: `wc -l` may have leading WSLibravatar Torsten Bögershausen1-0/+1
Test scripts count number of lines in an output and check it againt its expectation. fb3340a6 ("test-lib: introduce test_line_count to measure files", 2010-10-31) introduced a helper to show a failure in such a test in a more readable way than comparing `wc -l` output with a number. Besides, on some platforms, "$(wc -l <file)" is padded with leading whitespace on the left, so test "$(wc -l <file)" = 4 would not work (most notably on macosX); the users of test_line_count helper would not suffer from such a portability glitch. Add a check in check-non-portable-shell.pl to find '"' between `wc -l` and '=' and hint the user about test_line_count(). Signed-off-by: Torsten Bögershausen <tboegi@web.de> Reviewed-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22Merge branch 'ew/empty-merge-with-dirty-index-maint' into ↵Libravatar Junio C Hamano1-5/+21
ew/empty-merge-with-dirty-index * ew/empty-merge-with-dirty-index-maint: merge-recursive: avoid incorporating uncommitted changes in a merge move index_has_changes() from builtin/am.c to merge.c for reuse t6044: recursive can silently incorporate dirty changes in a merge
2017-12-22merge-recursive: avoid incorporating uncommitted changes in a mergeLibravatar Elijah Newren1-1/+1
builtin/merge.c contains this important requirement for merge strategies: /* * At this point, we need a real merge. No matter what strategy * we use, it would operate on the index, possibly affecting the * working tree, and when resolved cleanly, have the desired * tree in the index -- this means that the index must be in * sync with the head commit. The strategies are responsible * to ensure this. */ merge-recursive does not do this check directly, instead it relies on unpack_trees() to do it. However, merge_trees() has a special check for the merge branch exactly matching the merge base; when it detects that situation, it returns early without calling unpack_trees(), because it knows that the HEAD commit already has the correct result. Unfortunately, it didn't check that the index matched HEAD, so after it returned, the outer logic ended up creating a merge commit that included something other than HEAD. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22t6044: recursive can silently incorporate dirty changes in a mergeLibravatar Elijah Newren1-5/+21
The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22t/helper/test-lazy-name-hash: fix compilationLibravatar Stefan Beller1-1/+1
I was compiling origin/master today with DEVELOPER compiler flags and was greeted by: t/helper/test-lazy-init-name-hash.c: In function ‘cmd_main’: t/helper/test-lazy-init-name-hash.c:172:5: error: ‘nr_threads_used’ may be used uninitilized in this function [-Werror=maybe-uninitialized] printf("avg [size %8d] [single %f] %c [multi %f %d]\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ nr, ~~~ (double)avg_single/1000000000, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (avg_single < avg_multi ? '<' : '>'), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (double)avg_multi/1000000000, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ nr_threads_used); ~~~~~~~~~~~~~~~~ t/helper/test-lazy-init-name-hash.c:115:6: note: ‘nr_threads_used’ was declared here int nr_threads_used; ^~~~~~~~~~~~~~~ I do not see how we can arrive at that line without having `nr_threads_used` initialized, as we'd have `count > 1` (which asserts that we ran the loop above at least once, such that it *should* be initialized). Just clear the variable at the beginning of the function to squelch the warning. Signed-off-by: Stefan Beller <sbeller@google.com> Acked-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-19t5573, t7612: clean up after unexpected success of 'pull' and 'merge'Libravatar Junio C Hamano2-8/+17
The previous steps added test_when_finished to tests that run 'git pull' or 'git merge' with expectation of success, so that the test after them can start from a known state even when their 'git pull' invocation unexpectedly fails. However, tests that run 'git pull' or 'git merge' expecting it not to succeed forgot to protect later tests the same way---if they unexpectedly succeed, the test after them would start from an unexpected state. Reset and checkout the initial commit after all these tests, whether they expect their invocations to succeed or fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>