From: Miklos Vajna <vmiklos@frugalware.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: [PATCH] Add new test to ensure git-merge handles pull.twohead and pull.octopus
Date: Sat, 7 Jun 2008 02:47:29 +0200 [thread overview]
Message-ID: <1212799649-3822-1-git-send-email-vmiklos@frugalware.org> (raw)
In-Reply-To: <7vmylzzdyo.fsf@gitster.siamese.dyndns.org>
Test if the given strategies are used and test the case when multiple
strategies are configured using a space separated list.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Thu, Jun 05, 2008 at 03:58:23PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > +test_expect_success 'merge c1 with c2' '
> > + git reset --hard c1 &&
>
> test that c0 and c1 do and c2 and c3 do not exist here, as it is
> cheap,
> and otherwise you may end up chasing wild-goose when somebody breaks
> git-reset. No need to do so in later tests in this script, but it is
> a
> cheap protection for yourself from others' mistakes ;-).
Done.
> > + git merge c2 &&
> > + test -e c1.c &&
> > + test -e c2.c
> > +'
>
> Nobody runs V7 that lacked "test -e" to run these test scripts, but
> you
> expect them to be regular files at this point of the test, so the
> correct
> way to spell these is with "test -f".
>
> In general, you are better off training yourself to think if you can
> use
> "test -f" before blindly using "test -e".
Sure, corrected.
> > +test_expect_success 'merge c1 with c2 and c3 (recursive in
> > pull.octopus)' '
> > + git reset --hard c1 &&
> > + git config pull.octopus "recursive" &&
> > + ! git merge c2 c3
>
> Is it because it should dump core, or is it because the command should
> decline to work, gracefully failing with an error message and non-zero
> exit status? Use "test_must_fail" to check for the latter.
Obviously the later, corrected.
> Don't you want to check how it fails and in what shape the command
> leaves
> the work tree? I am assuming that recursive sees more than one
> "remote"
> head and declines to work without touching work tree nor the index, so
> if
> that is what you expect, you should check for that. Otherwise, a
> regression that loses local changes will go unnoticed.
Hm yes. I added checks to ensure nothing happened.
> > +test_expect_success 'merge c1 with c2 and c3 (recursive and octopus
> > in pull.octopus)' '
> > + git reset --hard c1 &&
> > + git config pull.octopus "recursive octopus" &&
> > + git merge c2 c3
>
> Likewise, don't you want to check the result of the merge? Not just
> "merge exited with 0", but you would want to see that the HEAD has
> advanced, it has the expected parents, there is no unexpected local
> changes (because you did not have any when you started the merge), and
> it
> has the expected tree contents.
Corrected.
I'm sending the version I just pushed to my working branch.
t/t7601-merge-pull-config.sh | 72 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 72 insertions(+), 0 deletions(-)
create mode 100755 t/t7601-merge-pull-config.sh
diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
new file mode 100755
index 0000000..c0b550e
--- /dev/null
+++ b/t/t7601-merge-pull-config.sh
@@ -0,0 +1,72 @@
+#!/bin/sh
+
+test_description='git-merge
+
+Testing pull.* configuration parsing.'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo c0 >c0.c &&
+ git add c0.c &&
+ git commit -m c0 &&
+ git tag c0 &&
+ echo c1 >c1.c &&
+ git add c1.c &&
+ git commit -m c1 &&
+ git tag c1 &&
+ git reset --hard c0 &&
+ echo c2 >c2.c &&
+ git add c2.c &&
+ git commit -m c2 &&
+ git tag c2
+ git reset --hard c0 &&
+ echo c3 >c3.c &&
+ git add c3.c &&
+ git commit -m c3 &&
+ git tag c3
+'
+
+test_expect_success 'merge c1 with c2' '
+ git reset --hard c1 &&
+ test -f c0.c &&
+ test -f c1.c &&
+ test ! -f c2.c &&
+ test ! -f c3.c &&
+ git merge c2 &&
+ test -f c1.c &&
+ test -f c2.c
+'
+
+test_expect_success 'merge c1 with c2 (ours in pull.twohead)' '
+ git reset --hard c1 &&
+ git config pull.twohead ours &&
+ git merge c2 &&
+ test -f c1.c &&
+ ! test -f c2.c
+'
+
+test_expect_success 'merge c1 with c2 and c3 (recursive in pull.octopus)' '
+ git reset --hard c1 &&
+ git config pull.octopus "recursive" &&
+ test_must_fail git merge c2 c3 &&
+ test "$(git rev-parse c1)" = "$(git rev-parse HEAD)"
+'
+
+test_expect_success 'merge c1 with c2 and c3 (recursive and octopus in pull.octopus)' '
+ git reset --hard c1 &&
+ git config pull.octopus "recursive octopus" &&
+ git merge c2 c3 &&
+ test "$(git rev-parse c1)" != "$(git rev-parse HEAD)" &&
+ test "$(git rev-parse c1)" = "$(git rev-parse HEAD^1)" &&
+ test "$(git rev-parse c2)" = "$(git rev-parse HEAD^2)" &&
+ test "$(git rev-parse c3)" = "$(git rev-parse HEAD^3)"
+ test "$(git rev-parse c3)" = "$(git rev-parse HEAD^3)" &&
+ git diff --exit-code &&
+ test -f c0.c &&
+ test -f c1.c &&
+ test -f c2.c &&
+ test -f c3.c
+'
+
+test_done
--
1.5.6.rc0.dirty
next prev parent reply other threads:[~2008-06-07 0:48 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-05 20:44 [PATCH 00/10] Build in merge Miklos Vajna
2008-06-05 20:44 ` [PATCH 01/10] Move split_cmdline() to alias.c Miklos Vajna
2008-06-05 20:44 ` [PATCH 02/10] Move commit_list_count() to commit.c Miklos Vajna
2008-06-05 20:44 ` [PATCH 03/10] Move builtin-remote's skip_prefix() to git-compat-util.h Miklos Vajna
2008-06-05 20:44 ` [PATCH 04/10] Add new test to ensure git-merge handles pull.twohead and pull.octopus Miklos Vajna
2008-06-05 20:44 ` [PATCH 05/10] parseopt: add a new PARSE_OPT_ARGV0_IS_AN_OPTION option Miklos Vajna
2008-06-05 20:44 ` [PATCH 06/10] Move read_cache_unmerged() to read-cache.c Miklos Vajna
2008-06-05 20:44 ` [PATCH 07/10] git-fmt-merge-msg: make it useable from other builtins Miklos Vajna
2008-06-05 20:44 ` [PATCH 08/10] Introduce commit_list_append() in commit.c Miklos Vajna
2008-06-05 20:44 ` [PATCH 09/10] Introduce get_octopus_merge_bases() " Miklos Vajna
2008-06-05 20:44 ` [PATCH 10/10] Build in merge Miklos Vajna
2008-06-06 3:51 ` [PATCH 09/10] Introduce get_octopus_merge_bases() in commit.c Junio C Hamano
2008-06-06 5:53 ` Junio C Hamano
2008-06-06 12:28 ` Johannes Schindelin
2008-06-06 12:36 ` Johannes Schindelin
2008-06-06 15:36 ` Junio C Hamano
2008-06-07 21:38 ` [PATCH] " Miklos Vajna
2008-06-09 14:02 ` Johannes Schindelin
2008-06-09 22:43 ` Miklos Vajna
2008-06-09 22:55 ` Junio C Hamano
2008-06-09 23:08 ` Johannes Schindelin
2008-06-09 23:20 ` Junio C Hamano
2008-06-09 23:35 ` Miklos Vajna
2008-06-09 23:06 ` Junio C Hamano
2008-06-09 23:25 ` Miklos Vajna
2008-06-09 23:31 ` Johannes Schindelin
2008-06-09 23:41 ` Junio C Hamano
2008-06-10 0:03 ` Miklos Vajna
2008-06-10 2:43 ` Johannes Schindelin
2008-06-06 12:30 ` [PATCH 09/10] " Johannes Schindelin
2008-06-07 2:30 ` Miklos Vajna
2008-06-05 23:16 ` [PATCH 08/10] Introduce commit_list_append() " Junio C Hamano
2008-06-06 23:52 ` Miklos Vajna
2008-06-07 0:14 ` Junio C Hamano
2008-06-07 2:03 ` Miklos Vajna
2008-06-05 23:12 ` [PATCH 07/10] git-fmt-merge-msg: make it useable from other builtins Junio C Hamano
2008-06-07 1:04 ` Miklos Vajna
2008-06-09 8:58 ` Andreas Ericsson
2008-06-09 22:53 ` [PATCH] git-fmt-merge-msg: make it usable " Miklos Vajna
2008-06-05 23:05 ` [PATCH 06/10] Move read_cache_unmerged() to read-cache.c Junio C Hamano
2008-06-07 1:00 ` [PATCH] " Miklos Vajna
2008-06-05 22:58 ` [PATCH 04/10] Add new test to ensure git-merge handles pull.twohead and pull.octopus Junio C Hamano
2008-06-07 0:47 ` Miklos Vajna [this message]
2008-06-05 22:38 ` [PATCH 03/10] Move builtin-remote's skip_prefix() to git-compat-util.h Junio C Hamano
2008-06-06 23:42 ` [PATCH] Move parse-options's " Miklos Vajna
-- strict thread matches above, loose matches on Subject: below --
2008-06-29 13:30 [PATCH 04/15] Add new test to ensure git-merge handles pull.twohead and pull.octopus Olivier Marin
2008-06-29 14:51 ` [PATCH] " Miklos Vajna
2008-06-29 15:11 ` Miklos Vajna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1212799649-3822-1-git-send-email-vmiklos@frugalware.org \
--to=vmiklos@frugalware.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).