Re: [PATCH 2/7] t7900: Start testing usability of namespaced remote refs
On Tue, May 7, 2013 at 3:29 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
+test_expect_success 'work-around clone with namespaced remote refs' '
+ rm -rf client
+ git init client
+ (
+ cd client
+ git remote add origin ../server
+ git config --unset-all remote.origin.fetch
+ git config --add remote.origin.fetch
+refs/heads/*:refs/remotes/origin/heads/*
If you were to do this, I think you should drop the remote add
origin step and illustrate what configuration variables should be
prepared (at least minimally---the final implementation of git
clone --separate-remote-layout may add some other configuration
variable as a hint to say this remote is using the new layout or
somesuch) in this client repository.
Sure, I can change the test into doing:
cd client
git config remote.origin.url ../server
git config --add remote.origin.fetch
+refs/heads/*:refs/remotes/origin/heads/*
git config --add remote.origin.fetch
+refs/tags/*:refs/remotes/origin/tags/*
git config --add remote.origin.fetch
+refs/notes/*:refs/remotes/origin/notes/*
git config --add remote.origin.fetch
+refs/replace/*:refs/remotes/origin/replace/*
git config remote.origin.tagopt --no-tags
git fetch
git checkout master
That would make the test more self documenting.
I am not convinced that it is a good idea to reuse remotes/origin
hierarchy which traditionally has been branches-only like this,
though. It may be better to use
refs/$remotes_new_layout/origin/{heads,tags,...}/*
for a value of $remotes_new_layout that is different from remote,
and teach the dwim_ref() machinery to pay attention to it, to avoid
confusion. Otherwise, you wouldn't be able to tell between a topic
branch that works on tags named tags/refactor under the old layout,
and a tag that marks a good point in a refactoring effort refactor
under the new layout.
I see your point, although I'm not convinced it is common among users
to have branch names of the tags/* form (or tag names of the
heads/* form, for that matter). I'm also not sure it's worth messing
with the remotes name which has had a long time to work its way into
our brains and into git's user interface.
That said, I could have a go at using refs/peers/* instead of
refs/remotes/*, and see how that works out.
If it sticks, how pervasive do we want this renaming to be? I guess we
don't want to rename the git remote command to git peer just
yet... What about the config? Do we rename remote.origin.url to
peer.origin.url for new-style remotes? For how long do you
anticipate having peers and remotes living side-by-side as
concepts in git?
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] t7900: Start testing usability of namespaced remote refs
Johan Herland jo...@herland.net writes: That said, I could have a go at using refs/peers/* instead of refs/remotes/*, and see how that works out. Hmm, I had refs/track/ in mind. Perhaps peers may work as well. If it sticks, how pervasive do we want this renaming to be? I guess we don't want to rename the git remote command to git peer just yet. If we were to do this, I would expect that the transition would be similar to the way we introduced the separate remote layout. The effort was started at around v1.3.0 era and we allowed the users to choose the layout when they make a new clone for quite some time, until we made it the default at v1.5.0 boundary, IIRC. Let the user opt into using the new layout first, and then if the new layout turns out to be vastly more useful than the current one, then the userbase will welcome it as the new default (and otherwise, it won't become the new default). We _should_ be able to tell the layout being used by checking which of refs/peers/ or refs/remotes/ is populated, but I do not mind if we added core.remoteLayout configuration variable that explicitly tells us which, if such an explicit clue turns out necessary. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] t7900: Start testing usability of namespaced remote refs
Johan Herland jo...@herland.net writes:
+test_expect_success 'work-around clone with namespaced remote refs' '
+ rm -rf client
+ git init client
+ (
+ cd client
+ git remote add origin ../server
+ git config --unset-all remote.origin.fetch
+ git config --add remote.origin.fetch
+refs/heads/*:refs/remotes/origin/heads/*
If you were to do this, I think you should drop the remote add
origin step and illustrate what configuration variables should be
prepared (at least minimally---the final implementation of git
clone --separate-remote-layout may add some other configuration
variable as a hint to say this remote is using the new layout or
somesuch) in this client repository.
That would make the test more self documenting.
I am not convinced that it is a good idea to reuse remotes/origin
hierarchy which traditionally has been branches-only like this,
though. It may be better to use
refs/$remotes_new_layout/origin/{heads,tags,...}/*
for a value of $remotes_new_layout that is different from remote,
and teach the dwim_ref() machinery to pay attention to it, to avoid
confusion. Otherwise, you wouldn't be able to tell between a topic
branch that works on tags named tags/refactor under the old layout,
and a tag that marks a good point in a refactoring effort refactor
under the new layout.
+ git config --add remote.origin.fetch
+refs/tags/*:refs/remotes/origin/tags/*
+ git config --add remote.origin.fetch
+refs/notes/*:refs/remotes/origin/notes/*
+ git config --add remote.origin.fetch
+refs/replace/*:refs/remotes/origin/replace/*
+ git config remote.origin.tagopt --no-tags
+ git fetch
+ git checkout master
+ )
+ test_clone client
+'
+
+test_done
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] t7900: Start testing usability of namespaced remote refs
Some users are interested in fetching remote refs into a separate namespace
in the local repo. E.g. instead of the usual remote config:
[remote origin]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ...
they want to keep remote tags separate from local tags, and they may also
want to fetch other ref types:
[remote origin]
fetch = +refs/heads/*:refs/remotes/origin/heads/*
fetch = +refs/tags/*:refs/remotes/origin/tags/*
fetch = +refs/notes/*:refs/remotes/origin/notes/*
fetch = +refs/replace/*:refs/remotes/origin/replace/*
tagopt = --no-tags
url = ...
This configuration creates a separate namespace under refs/remotes/origin/*
mirroring the structure of local refs (under refs/*) where all the relevant
refs from the 'origin' remote can be found.
This patch introduces a test whose main purpose is to verify that git will
work comfortably with this kind of setup. For now, we only verify that it
is possible (though not exactly easy) to establish a clone with the above
configuration, and that fetching into it yields the expected result.
Signed-off-by: Johan Herland jo...@herland.net
---
t/t7900-working-with-namespaced-remote-refs.sh | 88 ++
1 file changed, 88 insertions(+)
create mode 100755 t/t7900-working-with-namespaced-remote-refs.sh
diff --git a/t/t7900-working-with-namespaced-remote-refs.sh
b/t/t7900-working-with-namespaced-remote-refs.sh
new file mode 100755
index 000..af03ac9
--- /dev/null
+++ b/t/t7900-working-with-namespaced-remote-refs.sh
@@ -0,0 +1,88 @@
+#!/bin/sh
+
+test_description='testing end-user usability of namespaced remote refs
+
+Set up a local repo with namespaced remote refs, like this:
+
+[remote origin]
+ fetch = +refs/heads/*:refs/remotes/origin/heads/*
+ fetch = +refs/tags/*:refs/remotes/origin/tags/*
+ fetch = +refs/notes/*:refs/remotes/origin/notes/*
+ fetch = +refs/replace/*:refs/remotes/origin/replace/*
+ tagopt = --no-tags
+ url = ...
+
+Test that the usual end-user operations work as expected with this setup.
+'
+
+. ./test-lib.sh
+
+test_expect_success 'setup server repo' '
+ git init server
+ (
+ cd server
+ test_commit server_master_a
+ git checkout -b other
+ test_commit server_other_b
+ git checkout master
+ test_commit server_master_b
+ )
+'
+
+server_master_a=$(git --git-dir=server/.git rev-parse --verify server_master_a)
+server_master_b=$(git --git-dir=server/.git rev-parse --verify server_master_b)
+server_other_b=$(git --git-dir=server/.git rev-parse --verify server_other_b)
+
+cat expect.refspecs EOF
++refs/heads/*:refs/remotes/origin/heads/*
++refs/tags/*:refs/remotes/origin/tags/*
++refs/notes/*:refs/remotes/origin/notes/*
++refs/replace/*:refs/remotes/origin/replace/*
+EOF
+
+cat expect.show-ref EOF
+$server_master_b refs/heads/master
+$server_master_b refs/remotes/origin/heads/master
+$server_other_b refs/remotes/origin/heads/other
+$server_master_a refs/remotes/origin/tags/server_master_a
+$server_master_b refs/remotes/origin/tags/server_master_b
+$server_other_b refs/remotes/origin/tags/server_other_b
+EOF
+
+test_clone() {
+ ( cd $1 git config --get-all remote.origin.fetch ) actual.refspecs
+ test_cmp expect.refspecs actual.refspecs
+ ( cd $1 git show-ref ) actual.show-ref
+ test_cmp expect.show-ref actual.show-ref
+}
+
+test_expect_failure 'clone with namespaced remote refs' '
+ git clone server client \
+ --config
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/heads/* \
+ --config
remote.origin.fetch=+refs/tags/*:refs/remotes/origin/tags/* \
+ --config
remote.origin.fetch=+refs/notes/*:refs/remotes/origin/notes/* \
+ --config
remote.origin.fetch=+refs/replace/*:refs/remotes/origin/replace/* \
+ --config remote.origin.tagopt --no-tags
+ test_clone client
+'
+
+# Work-around for the above failure
+test_expect_success 'work-around clone with namespaced remote refs' '
+ rm -rf client
+ git init client
+ (
+ cd client
+ git remote add origin ../server
+ git config --unset-all remote.origin.fetch
+ git config --add remote.origin.fetch
+refs/heads/*:refs/remotes/origin/heads/*
+ git config --add remote.origin.fetch
+refs/tags/*:refs/remotes/origin/tags/*
+ git config --add remote.origin.fetch
+refs/notes/*:refs/remotes/origin/notes/*
+ git config --add remote.origin.fetch
+refs/replace/*:refs/remotes/origin/replace/*
+ git config remote.origin.tagopt --no-tags
+ git fetch
+ git checkout master
+ )
+ test_clone client
+'
+
+test_done
--
1.8.1.3.704.g33f7d4f
--
To unsubscribe from this list: send the line
