[PATCH] Updated testcases for stgit pull with merge

[PATCH] Updated testcases for stgit pull with merge

[Yann Dirson]

[Sorry for the previous buggy post]

In the previous series, patch 7 mostly demonstrate that I have missed
the appearance of the --merged flag in stgit 0.9 push and pull
commands, so we could just amend this testcase with that flag.
However, it appears that common workflow of forgetting that flag, then
trying to undo the failed push, and re-pushing with the flag still shows
a problem, as hopefully shown by this updated testcase.

As for the testcase in patch 8, it still demonstrates a problem IMHO:
the push without the --merged flag should have failed in much the same
way this one does.  However, I have seen GNU patch showing a similar
behaviour, so it is maybe not stgit's fault.

-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

[PATCH] Test that pulls a patch creating a file that got modified afterwards

[Yann Dirson]

From: Yann Dirson <ydirson@altern.org>

This demonstrates an issue wite has bitten me more than once: the stg
branch adds a file in one patch, and modifies it in a later patch; then all
patches get integrated in upstream tree, and at "stg pull" time, stgit
believes there is a conflict, even when the patches are exactly the same.

This is normal as it requires the --merged flag on push or pull.  So
we rollback with "push --undo" and "push --merge" to finish.
---

 t/t1200-push-modified.sh |   64 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/t/t1200-push-modified.sh b/t/t1200-push-modified.sh
new file mode 100755
index 0000000..7847a38
--- /dev/null
+++ b/t/t1200-push-modified.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Yann Dirson
+#
+
+test_description='Exercise pushing patches applied upstream.
+
+Especially, consider the case of a patch that adds a file, while a
+subsequent one modifies it, so we have to use --merged for push to
+detect the merge.  Reproduce the common workflow where one does not
+specify --merged, then rollback and retry with the correct flag.'
+
+. ./test-lib.sh
+
+# don't need this repo, but better not drop it, see t1100
+#rm -rf .git
+
+# Need a repo to clone
+test_create_repo foo
+
+test_expect_success \
+    'Clone tree and setup changes' \
+    "stg clone foo bar &&
+     (cd bar && stg new p1 -m p1
+      printf 'a\nc\n' > file && stg add file && stg refresh &&
+      stg new p2 -m p2
+      printf 'a\nb\nc\n' > file && stg refresh
+     )
+"
+
+test_expect_success \
+    'Port those patches to orig tree' \
+    "(cd foo &&
+      GIT_DIR=../bar/.git git-format-patch --stdout bases/master..HEAD |
+      git-am -3 -k
+     )
+"
+
+test_expect_success \
+    'Pull to sync with parent, preparing for the problem' \
+    "(cd bar && stg pop --all &&
+      stg pull
+     )
+"
+
+test_expect_failure \
+    'Attempt to push the first of those patches without --merged' \
+    "(cd bar && stg push
+     )
+"
+
+test_expect_success \
+    'Rollback the push' \
+    "(cd bar && stg push --undo
+     )
+"
+
+test_expect_success \
+    'Push those patches while checking they were merged upstream' \
+    "(cd bar && stg push --merged --all
+     )
+"
+
+test_done