git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH] Add new test to ensure git-merge handles pull.twohead and pull.octopus

From
Miklos Vajna <vmiklos@frugalware.org>
Date
Jun 7, 2008, 00:47 UTC
Message-ID
<1212799649-3822-1-git-send-email-vmiklos@frugalware.org>
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:
Show 9 quoted lines
> > +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.
Show 14 quoted lines
> > +   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.
Show 9 quoted lines
> > +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.
Show 8 quoted lines
> 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.
Show 12 quoted lines
> > +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
Previous: Junio C HamanoNext: Junio C Hamano
Message 43 of 45 in “Build in merge”
  1. 00/10 Build in mergeMiklos Vajna, Jun 5, 2008
  2. 01/10 Move split_cmdline() to alias.cMiklos Vajna, Jun 5, 2008
  3. 02/10 Move commit_list_count() to commit.cMiklos Vajna, Jun 5, 2008
  4. 03/10 Move builtin-remote's skip_prefix() to git-compat-util.hMiklos Vajna, Jun 5, 2008
  5. 04/10 Add new test to ensure git-merge handles pull.twohead and pull.octopusMiklos Vajna, Jun 5, 2008
  6. 05/10 parseopt: add a new PARSE_OPT_ARGV0_IS_AN_OPTION optionMiklos Vajna, Jun 5, 2008
  7. 06/10 Move read_cache_unmerged() to read-cache.cMiklos Vajna, Jun 5, 2008
  8. 07/10 git-fmt-merge-msg: make it useable from other builtinsMiklos Vajna, Jun 5, 2008
  9. 08/10 Introduce commit_list_append() in commit.cMiklos Vajna, Jun 5, 2008
  10. 09/10 Introduce get_octopus_merge_bases() in commit.cMiklos Vajna, Jun 5, 2008
  11. 10/10 Build in mergeMiklos Vajna, Jun 5, 2008
  12. Junio C HamanoJun 6, 2008
  13. Junio C HamanoJun 6, 2008
  14. Johannes SchindelinJun 6, 2008
  15. Johannes SchindelinJun 6, 2008
  16. Junio C HamanoJun 6, 2008
  17. Introduce get_octopus_merge_bases() in commit.cMiklos Vajna, Jun 7, 2008
  18. Johannes SchindelinJun 9, 2008
  19. Introduce get_octopus_merge_bases() in commit.cMiklos Vajna, Jun 9, 2008
  20. Junio C HamanoJun 9, 2008
  21. Johannes SchindelinJun 9, 2008
  22. Junio C HamanoJun 9, 2008
  23. Miklos VajnaJun 9, 2008
  24. Junio C HamanoJun 9, 2008
  25. Miklos VajnaJun 9, 2008
  26. Johannes SchindelinJun 9, 2008
  27. Junio C HamanoJun 9, 2008
  28. Miklos VajnaJun 10, 2008
  29. Johannes SchindelinJun 10, 2008
  30. Johannes SchindelinJun 6, 2008
  31. Miklos VajnaJun 7, 2008
  32. Junio C HamanoJun 5, 2008
  33. Miklos VajnaJun 6, 2008
  34. Junio C HamanoJun 7, 2008
  35. Miklos VajnaJun 7, 2008
  36. Junio C HamanoJun 5, 2008
  37. Miklos VajnaJun 7, 2008
  38. Andreas EricssonJun 9, 2008
  39. git-fmt-merge-msg: make it usable from other builtinsMiklos Vajna, Jun 9, 2008
  40. Junio C HamanoJun 5, 2008
  41. Move read_cache_unmerged() to read-cache.cMiklos Vajna, Jun 7, 2008
  42. Junio C HamanoJun 5, 2008
  43. Add new test to ensure git-merge handles pull.twohead and pull.octopusMiklos Vajna, Jun 7, 2008
  44. Junio C HamanoJun 5, 2008
  45. Move parse-options's skip_prefix() to git-compat-util.hMiklos Vajna, Jun 6, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.