git p4: gracefully fail if some commits could not be applied

If a commit fails to apply cleanly to the p4 tree, an interactive
prompt asks what to do next.  In all cases (skip, apply, write),
the behavior after the prompt had a few problems.

Change it so that it does not claim erroneously that all commits
were applied.  Instead list the set of the patches under
consideration, and mark with an asterisk those that were
applied successfully.  Like this example:

    Applying 592f1f9 line5 in file1 will conflict
    ...
    Unfortunately applying the change failed!
    What do you want to do?
    [s]kip this patch / [a]pply the patch forcibly and with .rej files / [w]rite the patch to a file (patch.txt) s
    Skipping! Good luck with the next patches...
    //depot/file1#4 - was edit, reverted
    Applying b8db1c6 okay_commit_after_skip
    ...
    Change 6 submitted.
    Applied only the commits marked with '*':
      592f1f9 line5 in file1 will conflict
    * b8db1c6 okay_commit_after_skip

Do not try to sync and rebase unless all patches were applied.
If there was a conflict during the submit, there is sure to be one
at the rebase.  Let the user to do the sync and rebase manually.

This changes how a couple tets in t9810-git-p4-rcs.sh behave:

    - git p4 now does not leave files open and edited in the
      client

    - If a git commit contains a change to a file that was
      deleted in p4, the test used to check that the sync/rebase
      loop happened after the failure to apply the change.  Since
      now sync/rebase does not happen after failure, do not test
      this.  Normal rebase machinery, outside of git p4, will let
      rebase --skip work.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

1 files changed, 3 insertions, 47 deletions

diff --git a/t/t9810-git-p4-rcs.sh b/t/t9810-git-p4-rcs.sh
index e9daa9c..fe30ad8 100755
--- a/t/t9810-git-p4-rcs.sh
+++ b/t/t9810-git-p4-rcs.sh
@@ -160,9 +160,6 @@ test_expect_success 'cleanup after failure' '
 # the cli file so that submit will get a conflict.  Make sure that
 # scrubbing doesn't make a mess of things.
 #
-# Assumes that git-p4 exits leaving the p4 file open, with the
-# conflict-generating patch unapplied.
-#
 # This might happen only if the git repo is behind the p4 repo at
 # submit time, and there is a conflict.
 #
@@ -181,14 +178,11 @@ test_expect_success 'do not scrub plain text' '
 			sed -i "s/^line5/line5 p4 edit/" file_text &&
 			p4 submit -d "file5 p4 edit"
 		) &&
-		! git p4 submit &&
+		echo s | test_expect_code 1 git p4 submit &&
 		(
-			# exepct something like:
-			#    file_text - file(s) not opened on this client
-			# but not copious diff output
+			# make sure the file is not left open
 			cd "$cli" &&
-			p4 diff file_text >wc &&
-			test_line_count = 1 wc
+			! p4 fstat -T action file_text
 		)
 	)
 '
@@ -343,44 +337,6 @@ test_expect_failure 'Add keywords in git which do not match the default p4 value
 	)
 '
 
-# Check that the existing merge conflict handling still works.
-# Modify kwfile1.c in git, and delete in p4. We should be able
-# to skip the git commit.
-#
-test_expect_success 'merge conflict handling still works' '
-	test_when_finished cleanup_git &&
-	(
-		cd "$cli" &&
-		echo "Hello:\$Id\$" >merge2.c &&
-		echo "World" >>merge2.c &&
-		p4 add -t ktext merge2.c &&
-		p4 submit -d "add merge test file"
-	) &&
-	git p4 clone --dest="$git" //depot &&
-	(
-		cd "$git" &&
-		sed -e "/Hello/d" merge2.c >merge2.c.tmp &&
-		mv merge2.c.tmp merge2.c &&
-		git add merge2.c &&
-		git commit -m "Modifying merge2.c"
-	) &&
-	(
-		cd "$cli" &&
-		p4 delete merge2.c &&
-		p4 submit -d "remove merge test file"
-	) &&
-	(
-		cd "$git" &&
-		test -f merge2.c &&
-		git config git-p4.skipSubmitEdit true &&
-		git config git-p4.attemptRCSCleanup true &&
-		!(echo "s" | git p4 submit) &&
-		git rebase --skip &&
-		! test -f merge2.c
-	)
-'
-
-
 test_expect_success 'kill p4d' '
 	kill_p4d
 '