summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2015-04-14Merge branch 'jc/update-instead-into-void'Libravatar Junio C Hamano1-1/+54
A push into an unborn branch, with "receive.denyCurrentBranch" set to "updateInstead", did not check out the working tree as expected. * jc/update-instead-into-void: push-to-deploy: allow pushing into an unborn branch and updating it
2015-04-01push-to-deploy: allow pushing into an unborn branch and updating itLibravatar Junio C Hamano1-1/+54
Setting receive.denycurrentbranch to updateinstead and pushing into the current branch, when the working tree and the index is truly clean, is supposed to reset the working tree and the index to match the tree of the pushed commit. This did not work when pushing into an unborn branch. The code that drives push-to-checkout hook needs no change, as the interface is defined so that hook can decide what to do when the push is coming to an unborn branch and take an appropriate action since the beginning. Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-26Merge branch 'jk/test-chain-lint'Libravatar Junio C Hamano102-773/+459
People often forget to chain the commands in their test together with &&, leaving a failure from an earlier command in the test go unnoticed. The new GIT_TEST_CHAIN_LINT mechanism allows you to catch such a mistake more easily. * jk/test-chain-lint: (36 commits) t9001: drop save_confirm helper t0020: use test_* helpers instead of hand-rolled messages t: simplify loop exit-code status variables t: fix some trivial cases of ignored exit codes in loops t7701: fix ignored exit code inside loop t3305: fix ignored exit code inside loop t0020: fix ignored exit code inside loops perf-lib: fix ignored exit code inside loop t6039: fix broken && chain t9158, t9161: fix broken &&-chain in git-svn tests t9104: fix test for following larger parents t4104: drop hand-rolled error reporting t0005: fix broken &&-chains t7004: fix embedded single-quotes t0050: appease --chain-lint t9001: use test_when_finished t4117: use modern test_* helpers t6034: use modern test_* helpers t1301: use modern test_* helpers t0020: use modern test_* helpers ...
2015-03-25Merge branch 'tg/test-index-v4'Libravatar Junio C Hamano1-3/+12
A test fix. * tg/test-index-v4: t1700: make test pass with index-v4
2015-03-25Merge branch 'jk/prune-with-corrupt-refs'Libravatar Junio C Hamano1-0/+114
"git prune" used to largely ignore broken refs when deciding which objects are still being used, which could spread an existing small damage and make it a larger one. * jk/prune-with-corrupt-refs: refs.c: drop curate_packed_refs repack: turn on "ref paranoia" when doing a destructive repack prune: turn on ref_paranoia flag refs: introduce a "ref paranoia" flag t5312: test object deletion code paths in a corrupted repository
2015-03-25Merge branch 'jk/fetch-pack'Libravatar Junio C Hamano1-3/+10
"git fetch" that fetches a commit using the allow-tip-sha1-in-want extension could have failed to fetch all the requested refs. * jk/fetch-pack: fetch-pack: remove dead assignment to ref->new_sha1 fetch_refs_via_pack: free extra copy of refs filter_ref: make a copy of extra "sought" entries filter_ref: avoid overwriting ref->old_sha1 with garbage
2015-03-25Merge branch 'dj/log-graph-with-no-walk'Libravatar Junio C Hamano4-7/+19
"git log --graph --no-walk A B..." is a otcnflicting request that asks nonsense; no-walk tells us show discrete points in the history, while graph asks to draw connections between these discrete points. Forbid the combination. * dj/log-graph-with-no-walk: revision: forbid combining --graph and --no-walk
2015-03-25Merge branch 'kd/rev-list-bisect-first-parent'Libravatar Junio C Hamano1-0/+4
"git rev-list --bisect --first-parent" does not work (yet) and can even cause SEGV; forbid it. "git log --bisect --first-parent" would not be useful until "git bisect --first-parent" materializes, so it is also forbidden for now. * kd/rev-list-bisect-first-parent: rev-list: refuse --first-parent combined with --bisect
2015-03-25Merge branch 'ct/prompt-untracked-fix'Libravatar Junio C Hamano1-0/+11
The prompt script (in contrib/) did not show the untracked sign when working in a subdirectory without any untracked files. * ct/prompt-untracked-fix: git prompt: use toplevel to find untracked files
2015-03-25t9001: drop save_confirm helperLibravatar Jeff King1-10/+5
The idea of this helper is that we want to save the current value of a config variable and then restore it again after the test completes. However, there's no point in actually saving the value; it should always be restored to the string "never" (which you can confirm by instrumenting save_confirm to print the value it finds). Let's just replace it with a single test_when_finished call. Suggested-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25t0020: use test_* helpers instead of hand-rolled messagesLibravatar Jeff King1-33/+5
These tests are not wrong, but it is much shorter and more idiomatic to say "verbose" or "test_must_fail" rather than printing our own messages on failure. Likewise, there is no need to say "happy" at the end of a test; the test suite takes care of that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25t: simplify loop exit-code status variablesLibravatar Jeff King2-16/+6
Since shell loops may drop the exit code of failed commands inside the loop, some tests try to keep track of the status by setting a variable. This can end up cumbersome and hard to read; it is much simpler to just exit directly from the loop using "return 1" (since each case is either in a helper function or inside a test snippet). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25t: fix some trivial cases of ignored exit codes in loopsLibravatar Jeff King10-28/+24
These are all cases where we do a setup step of the form: for i in $foo; do set_up $i || break done && more_setup would not notice a failure in set_up (because break always returns a 0 exit code). These are just setup steps that we do not expect to fail, but it does not hurt to be defensive. Most can be fixed by converting the "break" to a "return 1" (since we eval our tests inside a function for just this purpose). A few of the loops are inside subshells, so we can use just "exit 1" to break out of the subshell. And a few can actually be made shorter by just unrolling the loop. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25t7701: fix ignored exit code inside loopLibravatar Jeff King1-1/+1
When checking a list of file mtimes, we use a loop and break out early from the loop if any entry does not match. However, the exit code of a loop exited via break is always 0, meaning that the test will fail to notice we had a mismatch. Since the loop is inside a function, we can fix this by doing an early "return 1". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25t3305: fix ignored exit code inside loopLibravatar Jeff King1-6/+3
When we test deleting notes, we run "git notes remove" in a loop. However, the exit value of the loop will only reflect the final note we process. We should break out of the loop with a failing exit code as soon as we see a problem. Note that we can call "exit 1" here without explicitly creating a subshell, because the while loop on the right-hand side of a pipe executes in its own implicit subshell. Note also that the "break" above does not suffer the same problem; it is meant to exit the loop early at a certain number of iterations. We can bump it into the conditional of the loop to make this more obvious. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25t0020: fix ignored exit code inside loopsLibravatar Jeff King1-35/+19
A loop like: for f in one two; do something $f || break done will correctly break out of the loop when we see a failure of one item, but the resulting exit code will always be zero. We can fix that by putting the loop into a function or subshell, but in this case it is simpler still to just unroll the loop. We do add a helper function, which hopefully makes the end result even more readable (in addition to being shorter). Reported-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25perf-lib: fix ignored exit code inside loopLibravatar Jeff King1-1/+1
When copying the test repository, we try to detect whether the copy succeeded. However, most of the heavy lifting is done inside a for loop, where our "break" will lose the exit code of the failing "cp". We can take advantage of the fact that we are in a subshell, and just "exit 1" to break out with a code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-23Merge branch 'jk/test-annoyances'Libravatar Junio C Hamano5-15/+24
Test fixes. * jk/test-annoyances: t5551: make EXPENSIVE test cheaper t5541: move run_with_cmdline_limit to test-lib.sh t: pass GIT_TRACE through Apache t: redirect stderr GIT_TRACE to descriptor 4 t: translate SIGINT to an exit
2015-03-23Merge branch 'jk/smart-http-hide-refs'Libravatar Junio C Hamano1-0/+11
The transfer.hiderefs support did not quite work for smart-http transport. * jk/smart-http-hide-refs: upload-pack: do not check NULL return of lookup_unknown_object upload-pack: fix transfer.hiderefs over smart-http
2015-03-22t6039: fix broken && chainLibravatar Torsten Bögershausen1-1/+1
Add missing &&, detected by the --chain-lint option Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20Merge branch 'mg/log-decorate-HEAD'Libravatar Junio C Hamano2-4/+4
Output from "git log --decorate" mentions HEAD when it points at a tip of an branch differently from a detached HEAD. This is a potentially backward-incompatible change. * mg/log-decorate-HEAD: log: decorate HEAD with branch name
2015-03-20Merge branch 'jc/decorate-leaky-separator-color'Libravatar Junio C Hamano1-8/+8
"git log --decorate" did not reset colors correctly around the branch names. * jc/decorate-leaky-separator-color: log --decorate: do not leak "commit" color into the next item Documentation/config.txt: simplify boolean description in the syntax section Documentation/config.txt: describe 'color' value type in the "Values" section Documentation/config.txt: have a separate "Values" section Documentation/config.txt: describe the structure first and then meaning Documentation/config.txt: explain multi-valued variables once Documentation/config.txt: avoid unnecessary negation
2015-03-20Merge branch 'mg/verify-commit'Libravatar Junio C Hamano1-2/+2
Workarounds for certain build of GPG that triggered false breakage in a test. * mg/verify-commit: t7510: do not fail when gpg warns about insecure memory
2015-03-20Merge branch 'km/bsd-shells'Libravatar Junio C Hamano1-2/+2
Portability fixes and workarounds for shell scripts have been added to help BSD-derived systems. * km/bsd-shells: t5528: do not fail with FreeBSD shell help.c: use SHELL_PATH instead of hard-coded "/bin/sh" git-compat-util.h: move SHELL_PATH default into header git-instaweb: use @SHELL_PATH@ instead of /bin/sh git-instaweb: allow running in a working tree subdirectory
2015-03-20Merge branch 'mg/detached-head-report'Libravatar Junio C Hamano1-1/+38
"git branch" on a detached HEAD always said "(detached from xyz)", even when "git status" would report "detached at xyz". The HEAD is actually at xyz and haven't been moved since it was detached in such a case, but the user cannot read what the current value of HEAD is when "detached from" is used. * mg/detached-head-report: branch: name detached HEAD analogous to status wt-status: refactor detached HEAD analysis
2015-03-20Merge branch 'kn/git-cd-to-empty'Libravatar Junio C Hamano1-0/+10
"git -C '' subcmd" refused to work in the current directory, unlike "cd ''" which silently behaves as a no-op. * kn/git-cd-to-empty: git: treat "git -C '<path>'" as a no-op when <path> is empty
2015-03-20Merge branch 'nd/versioncmp-prereleases'Libravatar Junio C Hamano1-0/+28
The versionsort.prerelease configuration variable can be used to specify that v1.0-pre1 comes before v1.0. * nd/versioncmp-prereleases: config.txt: update versioncmp.prereleaseSuffix versionsort: support reorder prerelease suffixes
2015-03-20refs.c: drop curate_packed_refsLibravatar Jeff King1-1/+1
When we delete a ref, we have to rewrite the entire packed-refs file. We take this opportunity to "curate" the packed-refs file and drop any entries that are crufty or broken. Dropping broken entries (e.g., with bogus names, or ones that point to missing objects) is actively a bad idea, as it means that we lose any notion that the data was there in the first place. Aside from the general hackiness that we might lose any information about ref "foo" while deleting an unrelated ref "bar", this may seriously hamper any attempts by the user at recovering from the corruption in "foo". They will lose the sha1 and name of "foo"; the exact pointer may still be useful even if they recover missing objects from a different copy of the repository. But worse, once the ref is gone, there is no trace of the corruption. A follow-up "git prune" may delete objects, even though it would otherwise bail when seeing corruption. We could just drop the "broken" bits from curate_packed_refs, and continue to drop the "crufty" bits: refs whose loose counterpart exists in the filesystem. This is not wrong to do, and it does have the advantage that we may write out a slightly smaller packed-refs file. But it has two disadvantages: 1. It is a potential source of races or mistakes with respect to these refs that are otherwise unrelated to the operation. To my knowledge, there aren't any active problems in this area, but it seems like an unnecessary risk. 2. We have to spend time looking up the matching loose refs for every item in the packed-refs file. If you have a large number of packed refs that do not change, that outweighs the benefit from writing out a smaller packed-refs file (it doesn't get smaller, and you do a bunch of directory traversal to find that out). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20repack: turn on "ref paranoia" when doing a destructive repackLibravatar Jeff King1-1/+1
If we are repacking with "-ad", we will drop any unreachable objects. Likewise, using "-Ad --unpack-unreachable=<time>" will drop any old, unreachable objects. In these cases, we want to make sure the reachability we compute with "--all" is complete. We can do this by passing GIT_REF_PARANOIA=1 in the environment to pack-objects. Note that "-Ad" is safe already, because it only loosens unreachable objects. It is up to "git prune" to avoid deleting them. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20prune: turn on ref_paranoia flagLibravatar Jeff King1-2/+2
Prune should know about broken objects at the tips of refs, so that we can feed them to our traversal rather than ignoring them. It's better for us to abort the operation on the broken object than it is to start deleting objects with an incomplete view of the reachability namespace. Note that for missing objects, aborting is the best we can do. For a badly-named ref, we technically could use its sha1 as a reachability tip. However, the iteration code just feeds us a null sha1, so there would be a reasonable amount of code involved to pass down our wishes. It's not really worth trying to do better, because this is a case that should happen extremely rarely, and the message we provide: fatal: unable to parse object: refs/heads/bogus:name is probably enough to point the user in the right direction. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t5312: test object deletion code paths in a corrupted repositoryLibravatar Jeff King1-0/+114
When we are doing a destructive operation like "git prune", we want to be extra careful that the set of reachable tips we compute is valid. If there is any corruption or oddity, we are better off aborting the operation and letting the user figure things out rather than plowing ahead and possibly deleting some data that cannot be recovered. The tests here include: 1. Pruning objects mentioned only be refs with invalid names. This used to abort prior to d0f810f (refs.c: allow listing and deleting badly named refs, 2014-09-03), but since then we silently ignore the tip. Likewise, we test repacking that can drop objects (either "-ad", which drops anything unreachable, or "-Ad --unpack-unreachable=<time>", which tries to optimize out a loose object write that would be directly pruned). 2. Pruning objects when some refs point to missing objects. We don't know whether any dangling objects would have been reachable from the missing objects. We are better to keep them around, as they are better than nothing for helping the user recover history. 3. Packed refs that point to missing objects can sometimes be dropped. By itself, this is more of an annoyance (you do not have the object anyway; even if you can recover it from elsewhere, all you are losing is a placeholder for your state at the time of corruption). But coupled with (2), if we drop the ref and then go on to prune, we may lose unrecoverable objects. Note that we use test_might_fail for some of the operations. In some cases, it would be appropriate to abort the operation, and in others, it might be acceptable to continue but taking the information into account. The tests don't care either way, and check only for data loss. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t1700: make test pass with index-v4Libravatar Thomas Gummerer1-3/+12
The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when the test suite is run with TEST_GIT_INDEX_VERSION=4. Fix it. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t9158, t9161: fix broken &&-chain in git-svn testsLibravatar Michael J Gruber2-7/+7
All of these cases are moderate since they would most probably not lead to missed failing tests; either they would fail otherwise, or fail a rm in test_when_finished only. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t9104: fix test for following larger parentsLibravatar Michael J Gruber1-4/+6
This test is special for several reasons: It ends with a "true" statement, which should be a no-op. It is not because the &&-chain is broken right before it. Also, looking at what the test intended to test according to 7f578c5 (git-svn: --follow-parent now works on sub-directories of larger branches, 2007-01-24) it is not clear how it would achieve that with the given steps. Amend the test to include the second svn id to be tested for, and change the tested refs to the ones which are to be expected, and which make the test pass. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t4104: drop hand-rolled error reportingLibravatar Jeff King1-8/+2
This use of "||" fools --chain-lint into thinking the &&-chain is broken (and indeed, it is somewhat broken; a failure of update-index in these tests would show the patch file, even if we never got to the part of the test where we fed the patch to git-apply). The extra blocks were there to include more debugging output, but it hardly seems worth it; the user should know which command failed (because git-apply will produce error messages) and can look in the trash directory themselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t0005: fix broken &&-chainsLibravatar Jeff King1-2/+2
The ":" noop command always returns true, so it is fine to include these lines in an &&-chain (and it appeases --chain-lint). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t7004: fix embedded single-quotesLibravatar Jeff King1-1/+1
This test uses single quotes inside the single-quoted test snippet, which effectively makes the contents unquoted. Since they don't need quoted anyway, this isn't a problem, but let's switch them to double-quotes to make it more obviously correct. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t0050: appease --chain-lintLibravatar Jeff King1-4/+8
Some of the symlink tests check an either-or case using the "||". This is not wrong, but fools --chain-lint into thinking the &&-chain is broken (in fact, there is no && chain here). We can solve this by wrapping the "||" inside a {} block. This is a bit more verbose, but this construct is rare, and the {} block helps call attention to it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t9001: use test_when_finishedLibravatar Jeff King1-20/+10
The confirmation tests in t9001 all save the value of sendemail.confirm, do something to it, then restore it at the end, in a way that breaks the &&-chain (they are not wrong, because they save the $? value, but it fools --chain-lint). Instead, they can all use test_when_finished, and we can even make the code simpler by factoring out the shared lines. Note that we can _almost_ use test_config here, except that: 1. We do not restore the config with test_unconfig, but by setting it back to some prior value. 2. We are not always setting a config variable. Sometimes the change to be undone is unsetting it entirely. We could teach test_config to handle these cases, but it's not worth the complexity for a single call-site. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t4117: use modern test_* helpersLibravatar Jeff King1-56/+10
We can use test_must_fail and test_path_* to avoid some hand-rolled if statements. This makes the code shorter, and makes it more obvious when we are breaking the &&-chain. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t6034: use modern test_* helpersLibravatar Jeff King1-53/+13
These say roughly the same thing as the hand-rolled messages. We do lose the "merge did not complete" debug message, but merge and write-tree are prefectly capable of writing useful error messages when they fail. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t1301: use modern test_* helpersLibravatar Jeff King1-13/+7
This shortens the code and fixes some &&-chaining. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t0020: use modern test_* helpersLibravatar Jeff King1-116/+28
This test contains a lot of hand-rolled messages to show when the test fails. We can omit most of these by using "verbose" and "test_must_fail". A few of them are for update-index, but we can assume it produces reasonable error messages when it fails. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t6030: use modern test_* helpersLibravatar Jeff King1-60/+31
We can get rid of a lot of hand-rolled error messages by using test_must_fail and test_expect_code. The existing code was careful to use "|| return 1" when breaking the &&-chain, but it did fool --chain-lint; the new code is more idiomatic. We also add some uses of test_when_finished, which is less cryptic and more robust than putting code at the end of a test. In two cases we run "git bisect reset" from a subshell, which is a problem for test_when_finished (it would not run). However, in both of these cases, we are performing the tests in one-off sub-repos, so we do not need to clean up at all (and in fact it is nicer not to if the user wants to inspect the trash directory after a failure). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t9502: fix &&-chain breakageLibravatar Jeff King1-4/+6
This script misses a trivial &&-chain in one of its tests, but it also has a weird reverse: it includes an &&-chain outside of any test_expect block! This "cat" should never fail, but if it did, we would not notice, as it would cause us to skip the follow-on test entirely (which does not appear intentional; there are many later tests which rely on this cat). Let's instead move the setup into its own test_expect_success block, which is the standard practice nowadays. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t7201: fix &&-chain breakageLibravatar Jeff King1-13/+6
One of these breakages is in setup, but one is more severe and may miss a real test failure. These are pulled out from the rest, though, because we also clean up a few other anachronisms. The most interesting is the use of this here-doc construct: (cat >... <<EOF ... EOF ) && It looks like an attempt to make the &&-chaining more natural by letting it come at the end of the here-doc. But the extra sub-shell is so non-idiomatic (plus the lack of "<<-") that it ends up confusing. Since these are just using a single line, we can accomplish the same thing with a single printf (which also makes the use of tab more obvious than the verbatim whitespace). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t3600: fix &&-chain breakage for setup commandsLibravatar Jeff King1-18/+18
As with the earlier patch to fix "trivial" &&-chain breakage, these missing "&&" operators are not a serious problem (e.g., we do not expect "echo" to fail). Ironically, however, inserting them shows that some of the commands _do_ fail. Specifically, some of the tests start by making sure we are at a commit with the string "content" in the file "foo". However, running "git commit" may fail because the previous test left us in that state already, and there is nothing to commit. We could remove these commands entirely, but they serve to document the test's assumptions, as well as make it robust when an earlier test has failed. We could use test_might_fail to handle all cases, but that would miss an unrelated failure to make the commit. Instead, we can just pass the --allow-empty flag to git-commit, which means that it will not complain if our setup is a noop. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: avoid using ":" for commentsLibravatar Jeff King2-10/+10
The ":" is not a comment marker, but rather a noop command. Using it as a comment like: : do something cmd1 && : something else cmd2 breaks the &&-chain, and we would fail to notice if "cmd1" failed in this instance. We can just use regular "#" comments instead. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: wrap complicated expect_code users in a blockLibravatar Jeff King4-9/+13
If we are expecting a command to produce a particular exit code, we can use test_expect_code. However, some cases are more complicated, and want to accept one of a range of exit codes. For these, we end up with something like: cmd; case "$?" in ... That unfortunately breaks the &&-chain and fools --chain-lint. Since these special cases are so few, we can wrap them in a block, like this: { cmd; ret=$?; } && case "$ret" in ... This accomplishes the same thing, and retains the &&-chain (the exit status fed to the && is that of the assignment, which should always be true). It's technically longer, but it is probably a good thing for unusual code like this to stand out. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: use test_expect_code instead of hand-rolled comparisonLibravatar Jeff King3-44/+38
This makes our output in the event of a failure slightly nicer, and it means that we do not break the &&-chain. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>