git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

  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).