aboutsummaryrefslogtreecommitdiff
path: root/t/t9815-git-p4-submit-fail.sh
Commit message (Collapse)AuthorAge
* git-p4: avoid "stat" command in t9815 git-p4-submit-failLars Schneider2015-10-12
| | | | | | | | | Replace the stat command with the ls command to check file mode bits. The stats command is not available on Windows and has different command line options on OS X. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* test prerequisites: eradicate NOT_FOOJunio C Hamano2014-07-21
| | | | | | | | | | | | Support for Back when bdccd3c1 (test-lib: allow negation of prerequisites, 2012-11-14) introduced negated predicates (e.g. "!MINGW,!CYGWIN"), we already had 5 test files that use NOT_MINGW (and a few MINGW) as prerequisites. Let's not add NOT_FOO and rewrite existing ones as !FOO for both MINGW and CYGWIN. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git p4 test: use test_chmod for cygwinPete Wyckoff2013-01-26
| | | | | | | | | | | | | | | | | | This test does a commit that is a pure mode change, submits it to p4 but causes the submit to fail. It verifies that the state in p4 as well as the client directory are both unmodified after the failed submit. On cygwin, "chmod +x" does nothing, so use the test_chmod function to modify the index directly too. Also on cygwin, the executable bit cannot be seen in the filesystem, so avoid that part of the test. The checks of p4 state are still valid, though. Thanks-to: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-p4: add submit --conflict option and config varaiablePete Wyckoff2012-09-16
| | | | | | | | | | This allows specifying what to do when a conflict happens when applying a commit to p4, automating the interactive prompt. Signed-off-by: Pete Wyckoff <pw@padd.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git p4: revert deleted files after submit cancelPete Wyckoff2012-09-16
| | | | | | | | | | | | | The user can decide not to continue with a submission, by not saving the p4 submit template, then answering "no" to the "Submit anyway?" prompt. In this case, be sure to return the p4 client to its initial state. Deleted files were not reverted; fix this and test all cases. Signed-off-by: Pete Wyckoff <pw@padd.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git p4: test clean-up after failed submit, fix added filesPete Wyckoff2012-09-16
| | | | | | | | | | | | Test a variety of cases where a patch failed to apply to p4 and had to be cleaned up. If the patch failed to apply cleanly, do not try to remove to-be-added files, as they have not really been added yet. Signed-off-by: Pete Wyckoff <pw@padd.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git p4: move conflict prompt into run, add [q]uit inputPete Wyckoff2012-09-16
| | | | | | | | | | | | | | | When applying a commit to the p4 workspace fails, a prompt asks what to do next. This belongs up in run() instead of in applyCommit(), where run() can notice, for instance, that the prompt is unnecessary because this is the last commit. Offer two options about how to continue at conflict: [s]kip or [q]uit. Having an explicit "quit" option gives git p4 a chance to clean up, show the applied-commit summary, and do tag export. Signed-off-by: Pete Wyckoff <pw@padd.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git p4: gracefully fail if some commits could not be appliedPete Wyckoff2012-09-16
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>