summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2013-01-14Merge branch 'jk/unify-exit-code-by-receiving-signal' into maintLibravatar Junio C Hamano1-1/+1
* jk/unify-exit-code-by-receiving-signal: run-command: encode signal death as a positive integer
2013-01-14Merge branch 'jl/interrupt-clone-remove-separate-git-dir' into maintLibravatar Junio C Hamano1-1/+11
When "git clone --separate-git-dir=$over_there" is interrupted, it failed to remove the real location of the $GIT_DIR it created. This was most visible when interrupting a submodule update. * jl/interrupt-clone-remove-separate-git-dir: clone: support atomic operation with --separate-git-dir
2013-01-14Merge branch 'mk/maint-graph-infinity-loop' into maintLibravatar Junio C Hamano1-0/+10
* mk/maint-graph-infinity-loop: graph.c: infinite loop in git whatchanged --graph -m
2013-01-11Merge branch 'jk/enable-test-lint-by-default' into maintLibravatar Junio C Hamano1-0/+1
We have two simple and quick tests to catch common mistakes when writing test scripts, but we did not run them by default when running tests. * jk/enable-test-lint-by-default: tests: turn on test-lint by default
2013-01-11Merge branch 'ap/merge-stop-at-prepare-commit-msg-failure' into maintLibravatar Junio C Hamano1-0/+14
"git merge" started calling prepare-commit-msg hook like "git commit" does some time ago, but forgot to pay attention to the exit status of the hook. * ap/merge-stop-at-prepare-commit-msg-failure: merge: Honor prepare-commit-msg return code
2013-01-11Merge branch 'as/test-name-alias-uniquely' into maintLibravatar Junio C Hamano1-6/+6
* as/test-name-alias-uniquely: Use longer alias names in subdirectory tests
2013-01-11Merge branch 'ja/directory-attrs' into maintLibravatar Junio C Hamano1-0/+57
The attribute mechanism didn't allow limiting attributes to be applied to only a single directory itself with "path/" like the exclude mechanism does. * ja/directory-attrs: Add directory pattern matching to attributes
2013-01-11Merge branch 'jc/fetch-ignore-symref' into maintLibravatar Junio C Hamano1-0/+42
"git fetch --mirror" and fetch that uses other forms of refspec with wildcard used to attempt to update a symbolic ref that match the wildcard on the receiving end, which made little sense (the real ref that is pointed at by the symbolic ref would be updated anyway). Symbolic refs no longer are affected by such a fetch. * jc/fetch-ignore-symref: fetch: ignore wildcarded refspecs that update local symbolic refs
2013-01-10Merge branch 'tb/test-t9810-no-sed-i' into maintLibravatar Junio C Hamano1-10/+14
* tb/test-t9810-no-sed-i: t9810: Do not use sed -i
2013-01-10Merge branch 'tb/test-t9020-no-which' into maintLibravatar Junio C Hamano1-2/+2
* tb/test-t9020-no-which: t9020: which is not portable
2013-01-10Merge branch 'sp/shortlog-missing-lf' into maintLibravatar Junio C Hamano1-0/+24
* sp/shortlog-missing-lf: strbuf_add_wrapped*(): Remove unused return value shortlog: fix wrapping lines of wraplen
2013-01-10Merge branch 'nd/invalidate-i-t-a-cache-tree' into maintLibravatar Junio C Hamano1-0/+20
* nd/invalidate-i-t-a-cache-tree: cache-tree: invalidate i-t-a paths after generating trees cache-tree: fix writing cache-tree when CE_REMOVE is present cache-tree: replace "for" loops in update_one with "while" loops cache-tree: remove dead i-t-a code in verify_cache()
2013-01-08t1402: work around shell quoting issue on NetBSDLibravatar René Scharfe1-2/+4
The test fails for me on NetBSD 6.0.1 and reports: ok 1 - ref name '' is invalid ok 2 - ref name '/' is invalid ok 3 - ref name '/' is invalid with options --allow-onelevel ok 4 - ref name '/' is invalid with options --normalize error: bug in the test script: not 2 or 3 parameters to test-expect-success The alleged bug is in this line: invalid_ref NOT_MINGW '/' '--allow-onelevel --normalize' invalid_ref() constructs a test case description using its last argument, but the shell seems to split it up into two pieces if it contains a space. Minimal test case: # on NetBSD with /bin/sh $ a() { echo $#-$1-$2; } $ t="x"; a "${t:+$t}" 1-x- $ t="x y"; a "${t:+$t}" 2-x-y $ t="x y"; a "${t:+x y}" 1-x y- # and with bash $ t="x y"; a "${t:+$t}" 1-x y- $ t="x y"; a "${t:+x y}" 1-x y- This may be a bug in the shell, but here's a simple workaround: Construct the description string first and store it in a variable, and then use that to call test_expect_success(). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-08Merge branch 'jc/test-portability' into maintLibravatar Junio C Hamano2-6/+10
* jc/test-portability: t9020: use configured Python to run the test helper t3600: Avoid "cp -a", which is a GNUism
2013-01-08Merge branch 'jc/test-cvs-no-init-in-existing-dir' into maintLibravatar Junio C Hamano1-1/+2
* jc/test-cvs-no-init-in-existing-dir: t9200: let "cvs init" create the test repository
2013-01-08Merge branch 'jc/maint-test-portability' into maintLibravatar Junio C Hamano3-6/+8
* jc/maint-test-portability: t4014: fix arguments to grep t9502: do not assume GNU tar t0200: "locale" may not exist
2013-01-06run-command: encode signal death as a positive integerLibravatar Jeff King1-1/+1
When a sub-command dies due to a signal, we encode the signal number into the numeric exit status as "signal - 128". This is easy to identify (versus a regular positive error code), and when cast to an unsigned integer (e.g., by feeding it to exit), matches what a POSIX shell would return when reporting a signal death in $? or through its own exit code. So we have a negative value inside the code, but once it passes across an exit() barrier, it looks positive (and any code we receive from a sub-shell will have the positive form). E.g., death by SIGPIPE (signal 13) will look like -115 to us in inside git, but will end up as 141 when we call exit() with it. And a program killed by SIGPIPE but run via the shell will come to us with an exit code of 141. Unfortunately, this means that when the "use_shell" option is set, we need to be on the lookout for _both_ forms. We might or might not have actually invoked the shell (because we optimize out some useless shell calls). If we didn't invoke the shell, we will will see the sub-process's signal death directly, and run-command converts it into a negative value. But if we did invoke the shell, we will see the shell's 128+signal exit status. To be thorough, we would need to check both, or cast the value to an unsigned char (after checking that it is not -1, which is a magic error value). Fortunately, most callsites do not care at all whether the exit was from a code or from a signal; they merely check for a non-zero status, and sometimes propagate the error via exit(). But for the callers that do care, we can make life slightly easier by just using the consistent positive form. This actually fixes two minor bugs: 1. In launch_editor, we check whether the editor died from SIGINT or SIGQUIT. But we checked only the negative form, meaning that we would fail to notice a signal death exit code which was propagated through the shell. 2. In handle_alias, we assume that a negative return value from run_command means that errno tells us something interesting (like a fork failure, or ENOENT). Otherwise, we simply propagate the exit code. Negative signal death codes confuse us, and we print a useless "unable to run alias 'foo': Success" message. By encoding signal deaths using the positive form, the existing code just propagates it as it would a normal non-zero exit code. The downside is that callers of run_command can no longer differentiate between a signal received directly by the sub-process, and one propagated. However, no caller currently cares, and since we already optimize out some calls to the shell under the hood, that distinction is not something that should be relied upon by callers. Fix the same logic in t/test-terminal.perl for consistency [jc: raised by Jonathan in the discussion]. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Sixt <j6t@kdbg.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-05clone: support atomic operation with --separate-git-dirLibravatar Jens Lehmann1-1/+11
Since b57fb80a7d (init, clone: support --separate-git-dir for .git file) git clone supports the --separate-git-dir option to create the git dir outside the work tree. But when that option is used, the git dir won't be deleted in case the clone fails like it would be without this option. This makes clone lose its atomicity as in case of a failure a partly set up git dir is left behind. A real world example where this leads to problems is when "git submodule update" fails to clone a submodule and later calls to "git submodule update" stumble over the partially set up git dir and try to revive the submodule from there, which then fails with a not very user friendly error message. Fix that by updating the junk_git_dir variable (used to remember if and what git dir should be removed in case of failure) to the new value given with the --seperate-git-dir option. Also add a test for this to t5600 (and while at it fix the former last test to not cd into a directory to test for its existence but use "test -d" instead). Reported-by: Manlio Perillo <manlio.perillo@gmail.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-03merge: Honor prepare-commit-msg return codeLibravatar Antoine Pelisse1-0/+14
65969d4 (merge: honor prepare-commit-msg hook, 2011-02-14) tried to make "git commit" and "git merge" consistent, because a merge that required user assistance has to be concluded with "git commit", but back then only "git commit" triggered prepare-commit-msg hook. When it added a call to run the prepare-commit-msg hook, however, it forgot to check the exit code from the hook like "git commit" does, and ended up replacing one inconsistency with another. When prepare-commit-msg hook that is run from "git merge" exits with a non-zero status, abort the commit. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-03tests: turn on test-lint by defaultLibravatar Jeff King1-0/+1
The test Makefile knows about a few "lint" checks for common errors. However, they are not enabled as part of "make test" by default, which means that many people do not bother running them. Since they are both quick to run and accurate (i.e., no false positives), there should be no harm in turning them on and helping submitters catch errors earlier. We could just set: TEST_LINT = test-lint to enable all tests. But that would be unnecessarily annoying later on if we add slower or less accurate tests that should not be part of the default. Instead, we name the tests individually. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-01t9020: which is not portableLibravatar Torsten Bögershausen1-2/+2
Use type instead Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-01t9810: Do not use sed -iLibravatar Torsten Bögershausen1-10/+14
sed -i is not portable on all systems. Use sed with different input and output files. Utilize a tmp file whenever needed. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-28Use longer alias names in subdirectory testsLibravatar Aaron Schrab1-6/+6
When testing aliases in t/t1020-subdirectory.sh use longer names so that they're less likely to conflict with a git-* command somewhere in the $PATH. I have a git-ss command in my path which prevents the 'ss' alias from being used. This command will always fail for git.git, causing the test to fail. Even if the command succeeded, that would be a false success for the test since the alias wasn't actually used. A longer, more descriptive name will make it much less likely that somebody has a command in their $PATH which will shadow the alias created for the test. While here, use a longer name for the 'test' alias as well since that is also short and meaningful enough to make it not unlikely that somebody would have a command in their $PATH which will shadow that as well. Signed-off-by: Aaron Schrab <aaron@schrab.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-24t9200: let "cvs init" create the test repositoryLibravatar Junio C Hamano1-1/+2
Some platforms (e.g. NetBSD 6.0) seem to configure their CVS to allow "cvs init" in an existing directory only to members of "cvsadmin". Instead of preparing an empty directory and then running "cvs init" on it, let's run "cvs init" and let it create the necessary directory. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19t9020: use configured Python to run the test helperLibravatar Junio C Hamano1-3/+7
The test helper svnrdump_sim.py is used as "svnrdump" during the execution of this test, but the arrangement was not optimal: - it relied on symbolic links; - unportable "export VAR=VAL" was used; - GIT_BUILD_DIR variable was not quoted correctly; - it assumed that the Python interpreter is in /usr/bin/ and called "python" (i.e. not "python2.7" etc.) Rework this by writing a small shell script that spawns the right Python interpreter, using the right quoting. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19t3600: Avoid "cp -a", which is a GNUismLibravatar Junio C Hamano1-3/+3
With d4a7ffa (tests: "cp -a" is a GNUism, 2012-10-08), we got rid of most of them, but the ones in a topic that was still in flight were missed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19Merge branch 'jc/maint-test-portability' into 'jc/test-portability'Libravatar Junio C Hamano3-6/+8
* jc/maint-test-portability: t4014: fix arguments to grep t9502: do not assume GNU tar t0200: "locale" may not exist
2012-12-19t4014: fix arguments to grepLibravatar Junio C Hamano1-3/+3
These "expect-failure" tests were not looking for the right string in the patch file. For example: grep "^ *"S. E. Cipient" <scipient@example.com>\$" patch5 was looking for "^ *S." in these three files: "E." "Cipient <scipient@example.com>$" "patch5" With some implementations of grep, the lack of file "E." was reported as an error, leading to the failure of the test. With other implementations of grep, the pattern "^ *S." matched what was in patch5, without diagnosing the missing files as an error, and made these tests unexpectedly pass. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19t9502: do not assume GNU tarLibravatar Junio C Hamano1-1/+1
The check_snapshot function makes sure that no cruft outside the repository hierarchy is added to the tar archive. The output from "tar tf" on the resulting archive is inspected to see if there is anything that does not begin with "$prefix/". There are two issues with this implementation: - Traditional tar implemenations that do not understand pax_global_header will write it out as if it is a plain file at the top-level; - Some implementations of tar do not add trailing slash when showing a directory entry (i.e. the output line for the entire archive will show "$prefix", not "$prefix/"). Fix them so that what we want to validate can be tested with traditional tar implementations. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19t0200: "locale" may not existLibravatar Junio C Hamano1-2/+4
On systems without "locale" installed, t0200-gettext-basic.sh leaked error messages when checking if some test locales are available. Hide them, as they are not very useful. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-18Merge branch 'maint'Libravatar Junio C Hamano1-1/+4
* maint: t7004: do not create unneeded gpghome/gpg.conf when GPG is not used
2012-12-18t7004: do not create unneeded gpghome/gpg.conf when GPG is not usedLibravatar Junio C Hamano1-1/+4
These tests themselves are properly protected by the GPG prerequisite, but one of the set-up steps outside the test_expect_success block unconditionally assumed that there is a gpghome/ directory, which is not true if GPG is not being used. It may be a good idea to move the whole set-up steps in the test but that is a follow-up topic. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-18Merge branch 'jk/pickaxe-textconv' into maintLibravatar Junio C Hamano1-0/+12
"git log -p -S<string>" now looks for the <string> after applying the textconv filter (if defined); earlier it inspected the contents of the blobs without filtering.
2012-12-17Add directory pattern matching to attributesLibravatar Jean-Noël AVILA1-0/+57
The manpage of gitattributes says: "The rules how the pattern matches paths are the same as in .gitignore files" and the gitignore pattern matching has a pattern ending with / for directory matching. This rule is specifically relevant for the 'export-ignore' rule used for git archive. Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-15cache-tree: invalidate i-t-a paths after generating treesLibravatar Nguyễn Thái Ngọc Duy1-0/+20
Intent-to-add entries used to forbid writing trees so it was not a problem. After commit 3f6d56d (commit: ignore intent-to-add entries instead of refusing - 2012-02-07), we can generate trees from an index with i-t-a entries. However, the commit forgets to invalidate all paths leading to i-t-a entries. With fully valid cache-tree (e.g. after commit or write-tree), diff operations may prefer cache-tree to index and not see i-t-a entries in the index, because cache-tree does not have them. Reported-by: Jonathon Mah <me@JonathonMah.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-11fetch: ignore wildcarded refspecs that update local symbolic refsLibravatar Junio C Hamano1-0/+42
In a repository cloned from somewhere else, you typically have a symbolic ref refs/remotes/origin/HEAD pointing at the 'master' remote-tracking ref that is next to it. When fetching into such a repository with "git fetch --mirror" from another repository that was similarly cloned, the implied wildcard refspec refs/*:refs/* will end up asking to update refs/remotes/origin/HEAD with the object at refs/remotes/origin/HEAD at the remote side, while asking to update refs/remotes/origin/master the same way. Depending on the order the two updates happen, the latter one would find that the value of the ref before it is updated has changed from what the code expects. When the user asks to update the underlying ref via the symbolic ref explicitly without using a wildcard refspec, e.g. "git fetch $there refs/heads/master:refs/remotes/origin/HEAD", we should still let him do so, but when expanding wildcard refs, it will result in a more intuitive outcome if we simply ignore local symbolic refs. As the purpose of the symbolic ref refs/remotes/origin/HEAD is to follow the ref it points at (e.g. refs/remotes/origin/master), its value would change when the underlying ref is updated. Earlier commit da3efdb (receive-pack: detect aliased updates which can occur with symrefs, 2010-04-19) fixed a similar issue for "git push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-11shortlog: fix wrapping lines of wraplenLibravatar Steffen Prohaska1-0/+24
A recent commit [1] fixed a off-by-one wrapping error. As a side-effect, the conditional in add_wrapped_shortlog_msg() to decide whether to append a newline needs to be removed. The function should always append a newline, which was the case before the off-by-one fix, because strbuf_add_wrapped_text() never returns a value of wraplen; when it returns wraplen, the string does not end with a newline, so this caller needs to add one anyway. [1] 14e1a4e1ff70aff36db3f5d2a8b806efd0134d50 utf8: fix off-by-one wrapping of text Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-10Makefile: whitespace style fixes in macro definitionsLibravatar Stefano Lattarini1-1/+1
Consistently use a single space before and after the "=" (or ":=", "+=", etc.) in assignments to make macros. Granted, this was not a big deal, but I did find the needless inconsistency quite distracting. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-07Merge branch 'lt/diff-stat-show-0-lines' into maintLibravatar Junio C Hamano3-28/+71
"git diff --stat" miscounted the total number of changed lines when binary files were involved and hidden beyond --stat-count. It also miscounted the total number of changed files when there were unmerged paths. * lt/diff-stat-show-0-lines: t4049: refocus tests diff --shortstat: do not count "unmerged" entries diff --stat: do not count "unmerged" entries diff --stat: move the "total count" logic to the last loop diff --stat: use "file" temporary variable to refer to data->files[i] diff --stat: status of unmodified pair in diff-q is not zero test: add failing tests for "diff --stat" to t4049 Fix "git diff --stat" for interesting - but empty - file changes
2012-12-07Merge branch 'rr/t4041-cleanup'Libravatar Junio C Hamano1-249/+248
* rr/t4041-cleanup: t4041 (diff-submodule-option): modernize style t4041 (diff-submodule-option): rewrite add_file() routine t4041 (diff-submodule-option): parse digests sensibly t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs
2012-12-02t4041 (diff-submodule-option): modernize styleLibravatar Ramkumar Ramachandra1-230/+229
- Enclose tests in single quotes as opposed to double quotes. This is the prevalent style in other tests. - Remove the unused variable $head4_full. - Indent the expected output so that it lines up with the rest of the test text. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02t4041 (diff-submodule-option): rewrite add_file() routineLibravatar Ramkumar Ramachandra1-12/+12
Instead of "cd there and then come back", use the "cd there in a subshell" pattern. Also fix '&&' chaining in one place. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02t4041 (diff-submodule-option): parse digests sensiblyLibravatar Ramkumar Ramachandra1-7/+7
`git rev-list --max-count=1 HEAD` is a roundabout way of saying `git rev-parse --verify HEAD`; replace a bunch of instances of the former with the latter. Also, don't unnecessarily `cut -c1-7` the rev-parse output when the `--short` option is available. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29Merge branch 'pw/p4-various-fixes'Libravatar Junio C Hamano2-1/+59
* pw/p4-various-fixes: git p4: remove unneeded cmd initialization git p4: fix labelDetails typo in exception git p4 test: display unresolvable host error git p4: catch p4 errors when streaming file contents git p4: handle servers without move support git p4: catch p4 describe errors
2012-11-29Merge branch 'lt/diff-stat-show-0-lines'Libravatar Junio C Hamano1-3/+45
"git diff --stat" miscounted the total number of changed lines when binary files were involved and hidden beyond --stat-count. It also miscounted the total number of changed files when there were unmerged paths. * lt/diff-stat-show-0-lines: t4049: refocus tests diff --shortstat: do not count "unmerged" entries diff --stat: do not count "unmerged" entries diff --stat: move the "total count" logic to the last loop diff --stat: use "file" temporary variable to refer to data->files[i] diff --stat: status of unmodified pair in diff-q is not zero test: add failing tests for "diff --stat" to t4049
2012-11-29Merge branch 'fc/remote-hg'Libravatar Junio C Hamano1-1/+2
New remote helper for hg. * fc/remote-hg: (22 commits) remote-hg: fix for older versions of python remote-hg: fix for files with spaces remote-hg: avoid bad refs remote-hg: try the 'tip' if no checkout present remote-hg: fix compatibility with older versions of hg remote-hg: add missing config for basic tests remote-hg: the author email can be null remote-hg: add option to not track branches remote-hg: add extra author test remote-hg: add tests to compare with hg-git remote-hg: add bidirectional tests test-lib: avoid full path to store test results remote-hg: add basic tests remote-hg: fake bookmark when there's none remote-hg: add compat for hg-git author fixes remote-hg: add support for hg-git compat mode remote-hg: match hg merge behavior remote-hg: make sure the encoding is correct remote-hg: add support to push URLs remote-hg: add support for remote pushing ...
2012-11-29Merge branch 'jk/send-email-sender-prompt'Libravatar Junio C Hamano6-12/+136
General clean-ups in various areas, originally written to support a patch that later turned out to be unneeded. * jk/send-email-sender-prompt: t9001: check send-email behavior with implicit sender t: add tests for "git var" ident: keep separate "explicit" flags for author and committer ident: make user_ident_explicitly_given static t7502: factor out autoident prerequisite test-lib: allow negation of prerequisites
2012-11-29Merge branch 'fc/send-email-no-sender-prompt'Libravatar Junio C Hamano1-3/+2
* fc/send-email-no-sender-prompt: send-email: avoid questions when user has an ident
2012-11-29Merge branch 'jl/submodule-rm'Libravatar Junio C Hamano1-0/+17
Finishing touches to "git rm $submodule" that removes the working tree of a submodule. * jl/submodule-rm: Teach rm to remove submodules when given with a trailing '/'
2012-11-29Merge branch 'fc/completion-test-simplification'Libravatar Junio C Hamano1-82/+52
Clean up completion tests. Use of conslidated helper may make instrumenting one particular test during debugging of the test itself, but I think that issue should be addressed in some other way (e.g. making sure individual tests in 9902 can be skipped). * fc/completion-test-simplification: completion: simplify __gitcomp() test helper completion: refactor __gitcomp related tests completion: consolidate test_completion*() tests completion: simplify tests using test_completion_long() completion: standardize final space marker in tests completion: add comment for test_completion()