From: Mark Levedahl <mlevedahl@gmail.com>
To: gitster@pobox.com
Cc: git@vger.kernel.org, Mark Levedahl <mlevedahl@gmail.com>
Subject: [PATCH 7/7] Add t/t7401 - test submodule interaction with remotes machinery
Date: Sun, 3 Feb 2008 12:31:07 -0500 [thread overview]
Message-ID: <1202059867-1184-8-git-send-email-mlevedahl@gmail.com> (raw)
In-Reply-To: <1202059867-1184-7-git-send-email-mlevedahl@gmail.com>
This adds a sequence of tests to assure that the following two sequences
work:
git clone -o frotz <someurl> foo
cd foo
git submodule init
git submodule update
This should result in the master and subproject having "frotz" as the
name of the default remote (and origin undefined).
Then, in the same working directory
git remote add fork <some url>
git fetch fork
git checkout --track -b fork fork/<somebranch>
git submodule init
git submodule update
will retrive new submodules from remote "fork", and define fork in the
existing modules. Origin remains undefined.
Note: this latter case is a clear motivation for overriding "origin": after
the second test, the various submodules would have different ideas of
remote "origin": these would point to different servers. This would
entirely prevent the top-level branch.<name>.remote machinery from
controlling the project as there is no uniform naming of remotes.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
t/t7401-submodule-remote.sh | 104 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100755 t/t7401-submodule-remote.sh
diff --git a/t/t7401-submodule-remote.sh b/t/t7401-submodule-remote.sh
new file mode 100755
index 0000000..1a793db
--- /dev/null
+++ b/t/t7401-submodule-remote.sh
@@ -0,0 +1,104 @@
+#!/bin/sh
+
+test_description='Porcelain support for submodules with multiple remotes
+
+This test verifies operation of submodules using multiple remotes and
+differing remote per top-level branch. This includes ability to name the
+default something other than origin, to follow the top-level
+remote.<branch>, and to propagate definition of new remotes down to
+submodules as needed.
+'
+
+. ./test-lib.sh
+
+# the standard tests all work with one repo, but we need several..
+rm -rf .git
+
+test_expect_success 'Prepare master repository with 1 submodule' '
+ (
+ mkdir master &&
+ cd master &&
+ git init &&
+ echo "on master" > master.txt &&
+ git add master.txt &&
+ git commit -m "Add master.txt" &&
+ mkdir submod1 &&
+ cd submod1 &&
+ git init &&
+ echo "submod1" > submod1.txt &&
+ git add submod1.txt &&
+ git commit -m "Added submod1.txt" &&
+ cd .. &&
+ git submodule add ./submod1 submod1 &&
+ git commit -m "Added submodule submod1"
+ )
+'
+
+test_expect_success 'Clone master as fork' '
+ (
+ git clone master fork &&
+ cd fork &&
+ test "$(git remote)" = "origin" &&
+ git submodule init &&
+ git submodule update &&
+ test -e submod1/.git
+ )
+'
+
+test_expect_success 'Add second submodule in fork' '
+ (
+ cd fork &&
+ mkdir submod2 &&
+ cd submod2 &&
+ git init &&
+ echo "submod2" > submod2.txt &&
+ git add submod2.txt &&
+ git commit -m "Added submod2.txt" &&
+ cd .. &&
+ git submodule add ./submod2 submod2 &&
+ git commit -m "Added submodule submod2 on fork"
+ )
+'
+
+test_expect_success 'Clone master using frotz instead of origin' '
+ (
+ git clone -o frotz master worker &&
+ cd worker &&
+ test "$(git remote)" = "frotz"
+ )
+'
+
+test_expect_success 'Get submodules using frotz instead of origin' '
+ (
+ cd worker &&
+ git submodule init &&
+ git submodule update &&
+ test -e submod1/.git &&
+ cd submod1 &&
+ test "$(git remote)" = "frotz"
+ )
+'
+
+test_expect_success 'Update using fork to get additional submodule' '
+ (
+ cd worker &&
+ git remote add fork $(pwd)/../fork &&
+ git fetch fork &&
+ git checkout --track -b fork_master fork/master &&
+ git submodule init &&
+ git submodule update &&
+ test -e submod2/.git &&
+ cd submod2 &&
+ test "$(git remote)" = "fork" &&
+ cd ../submod1 &&
+ remotes1=$(git remote) &&
+ case $remotes1 in
+ fork*frotz|frotz*fork)
+ true ;;
+ *)
+ false ;;
+ esac
+ )
+'
+
+test_done
--
1.5.4.18.g43c18
next prev parent reply other threads:[~2008-02-03 17:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-03 17:31 [PATCH 0 of 7] [resend] - Improve handling remotes, origin, submodules Mark Levedahl
2008-02-03 17:31 ` [PATCH 1/7] Teach remote machinery about core.origin config variable Mark Levedahl
2008-02-03 17:31 ` [PATCH 2/7] git-remote - Unset core.origin when deleting the default remote Mark Levedahl
2008-02-03 17:31 ` [PATCH 3/7] git-clone - Set remotes.origin config variable Mark Levedahl
2008-02-03 17:31 ` [PATCH 4/7] git-submodule - Possibly inherit parent's default remote on init/clone Mark Levedahl
2008-02-03 17:31 ` [PATCH 5/7] Teach git-submodule to use top-level remote when updating subprojects Mark Levedahl
2008-02-03 17:31 ` [PATCH 6/7] git-submodule - Allow adding a submodule in-place Mark Levedahl
2008-02-03 17:31 ` Mark Levedahl [this message]
2008-02-03 22:43 ` [PATCH 0 of 7] [resend] - Improve handling remotes, origin, submodules Johannes Schindelin
2008-02-04 3:52 ` Mark Levedahl
2008-02-04 14:48 ` Johannes Schindelin
2008-02-04 17:24 ` Mark Levedahl
2008-02-04 18:15 ` Johannes Schindelin
2008-02-04 19:59 ` Junio C Hamano
2008-02-04 20:47 ` Johannes Schindelin
2008-02-04 21:40 ` Junio C Hamano
2008-02-04 21:49 ` Johannes Schindelin
2008-02-04 5:19 ` Steffen Prohaska
2008-02-04 14:55 ` Johannes Schindelin
-- strict thread matches above, loose matches on Subject: below --
2008-02-03 17:20 [PATCH 0 of 7] - Improve handling remotes, origin, and submodules Mark Levedahl
2008-02-03 17:20 ` [PATCH 1/7] Teach remote machinery about core.origin config variable Mark Levedahl
2008-02-03 17:20 ` [PATCH 2/7] git-remote - Unset core.origin when deleting the default remote Mark Levedahl
2008-02-03 17:20 ` [PATCH 3/7] git-clone - Set remotes.origin config variable Mark Levedahl
2008-02-03 17:20 ` [PATCH 4/7] git-submodule - Possibly inherit parent's default remote on init/clone Mark Levedahl
2008-02-03 17:20 ` [PATCH 5/7] Teach git-submodule to use top-level remote when updating subprojects Mark Levedahl
2008-02-03 17:20 ` [PATCH 6/7] git-submodule - Allow adding a submodule in-place Mark Levedahl
2008-02-03 17:20 ` [PATCH 7/7] Add t/t7401 - test submodule interaction with remotes machinery Mark Levedahl
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1202059867-1184-8-git-send-email-mlevedahl@gmail.com \
--to=mlevedahl@gmail.com \
--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.
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 NNTP newsgroup(s).