git/t/t9815-git-p4-submit-fail.sh

248 lines
5.5 KiB
Bash
Raw Normal View History

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>
2012-09-10 04:16:03 +08:00
#!/bin/sh
test_description='git p4 submit failure handling'
. ./lib-git-p4.sh
test_expect_success 'start p4d' '
start_p4d
'
test_expect_success 'init depot' '
(
cd "$cli" &&
p4 client -o | sed "/LineEnd/s/:.*/:unix/" | p4 client -i &&
echo line1 >file1 &&
p4 add file1 &&
p4 submit -d "line1 in file1"
)
'
test_expect_success 'conflict on one commit' '
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>
2012-09-10 04:16:03 +08:00
test_when_finished cleanup_git &&
git p4 clone --dest="$git" //depot &&
(
cd "$cli" &&
p4 open file1 &&
echo line2 >>file1 &&
p4 submit -d "line2 in file1"
) &&
(
# now this commit should cause a conflict
cd "$git" &&
git config git-p4.skipSubmitEdit true &&
echo line3 >>file1 &&
git add file1 &&
git commit -m "line3 in file1 will conflict" &&
test_expect_code 1 git p4 submit >out &&
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>
2012-09-10 04:16:03 +08:00
test_i18ngrep "No commits applied" out
)
'
test_expect_success 'conflict on second of two commits' '
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>
2012-09-10 04:16:03 +08:00
test_when_finished cleanup_git &&
git p4 clone --dest="$git" //depot &&
(
cd "$cli" &&
p4 open file1 &&
echo line3 >>file1 &&
p4 submit -d "line3 in file1"
) &&
(
cd "$git" &&
git config git-p4.skipSubmitEdit true &&
# this commit is okay
test_commit "first_commit_okay" &&
# now this submit should cause a conflict
echo line4 >>file1 &&
git add file1 &&
git commit -m "line4 in file1 will conflict" &&
test_expect_code 1 git p4 submit >out &&
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>
2012-09-10 04:16:03 +08:00
test_i18ngrep "Applied only the commits" out
)
'
test_expect_success 'conflict on first of two commits, skip' '
test_when_finished cleanup_git &&
git p4 clone --dest="$git" //depot &&
(
cd "$cli" &&
p4 open file1 &&
echo line4 >>file1 &&
p4 submit -d "line4 in file1"
) &&
(
cd "$git" &&
git config git-p4.skipSubmitEdit true &&
# this submit should cause a conflict
echo line5 >>file1 &&
git add file1 &&
git commit -m "line5 in file1 will conflict" &&
# but this commit is okay
test_commit "okay_commit_after_skip" &&
echo s | test_expect_code 1 git p4 submit >out &&
test_i18ngrep "Applied only the commits" out
)
'
test_expect_success 'conflict on first of two commits, quit' '
test_when_finished cleanup_git &&
git p4 clone --dest="$git" //depot &&
(
cd "$cli" &&
p4 open file1 &&
echo line7 >>file1 &&
p4 submit -d "line7 in file1"
) &&
(
cd "$git" &&
git config git-p4.skipSubmitEdit true &&
# this submit should cause a conflict
echo line8 >>file1 &&
git add file1 &&
git commit -m "line8 in file1 will conflict" &&
# but this commit is okay
test_commit "okay_commit_after_quit" &&
echo q | test_expect_code 1 git p4 submit >out &&
test_i18ngrep "No commits applied" out
)
'
#
# Cleanup after submit fail, all cases. Some modifications happen
# before trying to apply the patch. Make sure these are unwound
# properly. Put each one in a diff along with something that will
# obviously conflict. Make sure it is back to normal after.
#
test_expect_success 'cleanup edit p4 populate' '
(
cd "$cli" &&
echo text file >text &&
p4 add text &&
echo text+x file >text+x &&
chmod 755 text+x &&
p4 add text+x &&
p4 submit -d "populate p4"
)
'
setup_conflict() {
# clone before modifying file1 to force it to conflict
test_when_finished cleanup_git &&
git p4 clone --dest="$git" //depot &&
# ticks outside subshells
test_tick &&
(
cd "$cli" &&
p4 open file1 &&
echo $test_tick >>file1 &&
p4 submit -d "$test_tick in file1"
) &&
test_tick &&
(
cd "$git" &&
git config git-p4.skipSubmitEdit true &&
# easy conflict
echo $test_tick >>file1 &&
git add file1
# caller will add more and submit
)
}
test_expect_success 'cleanup edit after submit fail' '
setup_conflict &&
(
cd "$git" &&
echo another line >>text &&
git add text &&
git commit -m "conflict" &&
test_expect_code 1 git p4 submit
) &&
(
cd "$cli" &&
# make sure it is not open
! p4 fstat -T action text
)
'
test_expect_success 'cleanup add after submit fail' '
setup_conflict &&
(
cd "$git" &&
echo new file >textnew &&
git add textnew &&
git commit -m "conflict" &&
test_expect_code 1 git p4 submit
) &&
(
cd "$cli" &&
# make sure it is not there
# and that p4 thinks it is not added
# P4 returns 0 both for "not there but added" and
# "not there", so grep.
test_path_is_missing textnew &&
p4 fstat -T action textnew 2>&1 | grep "no such file"
)
'
test_expect_success 'cleanup delete after submit fail' '
setup_conflict &&
(
cd "$git" &&
git rm text+x &&
git commit -m "conflict" &&
test_expect_code 1 git p4 submit
) &&
(
cd "$cli" &&
# make sure it is there
test_path_is_file text+x &&
! p4 fstat -T action text+x
)
'
test_expect_success 'cleanup copy after submit fail' '
setup_conflict &&
(
cd "$git" &&
cp text text2 &&
git add text2 &&
git commit -m "conflict" &&
git config git-p4.detectCopies true &&
git config git-p4.detectCopiesHarder true &&
# make sure setup is okay
git diff-tree -r -C --find-copies-harder HEAD | grep text2 | grep C100 &&
test_expect_code 1 git p4 submit
) &&
(
cd "$cli" &&
test_path_is_missing text2 &&
p4 fstat -T action text2 2>&1 | grep "no such file"
)
'
test_expect_success 'cleanup rename after submit fail' '
setup_conflict &&
(
cd "$git" &&
git mv text text2 &&
git commit -m "conflict" &&
git config git-p4.detectRenames true &&
# make sure setup is okay
git diff-tree -r -M HEAD | grep text2 | grep R100 &&
test_expect_code 1 git p4 submit
) &&
(
cd "$cli" &&
test_path_is_missing text2 &&
p4 fstat -T action text2 2>&1 | grep "no such file"
)
'
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>
2012-09-10 04:16:03 +08:00
test_expect_success 'kill p4d' '
kill_p4d
'
test_done