This test uses a convoluted method to verify that "p4 help" errors
out when asked for help about an unknown command. In doing so, it
intentionally breaks the &&-chain. Simplify by employing the typical
"! command" idiom and a normal &&-chain instead.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test_must_fail should only be used for testing git commands. To test the
failure of other commands use `!`.
Reported-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use test_lazy_prereq to setup prerequisites for the p4 move
test. This both makes the test simpler and clearer, and also
means it no longer fails the new --chain-lint tests.
Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By using a tree with multiple identical files and allowing copy detection to
choose any one of them, the check in the test is unnecessarily complex. We can
simplify by:
* Modify source file (file2) before copying the file.
* Check that only file2 is the source in the output of "p4 filelog".
* Remove all "case" statements and replace them with simple tests to check
that source is "file2".
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
File file11 is copied from file2 and diff-tree correctly reports
this file as its the source. But it is possible that the diff-tree
algorithm detects file10, which was also copied from file2, as the
origin of the new file.
This fix uses a case statement to support both files as the source
of file11, as was done in other tests in this file.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An update to the tests in 2.1 era introduced a broken case statements
that lack closing esac.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The construct is error-prone; "test" being built-in in most modern
shells, the reason to avoid "test <cond> && test <cond>" spawning
one extra process by using a single "test <cond> -a <cond>" no
longer exists.
Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support for the "p4 move" command was added in 8e9497c (git p4:
add support for 'p4 move' in P4Submit, 2012-07-12), which checks
to make sure that the client and server support the command.
But older versions of p4d may not handle the "-k" argument, and
newer p4d allow disabling "p4 move" with a configuration setting.
Check for both these cases by testing a p4 move command on bogus
filenames and looking for strings in the error messages.
Reported-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For -M option (detectRenames) in P4Submit, use 'p4 move' rather
than 'p4 integrate'. Check Perforce server for exisitence of
'p4 move' and use it if present, otherwise revert to 'p4 integrate'.
[pw: wildcard-encode src/dest, add/update tests, tweak code]
Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original t9800 test code has a mix of assorted topics, some
of which are big enough to deserve their own homes.
Interdependencies between the topics make it confusing when
trying to study one in isolation. And it takes so long to run
that debugging an individual test is difficult.
Split out three big chunks of tests into their own files:
t9812-git-p4-wildcards.sh gets the 8 p4 wildcard tests
t9813-git-p4-preserve-users.sh gets the 4 --preserve-user tests
t9814-git-p4-rename.sh gets the 2 copy and rename tests
Test 9800 execution time drops from 29 sec to 9 sec. The
sequential time to run all tests is a slower due to the three
extra p4d startup/shutdown sequences, but the overall parallel
execution time is about the same, at 52 sec.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
