Re: [PATCH 2/7] t7900: Start testing usability of namespaced remote refs
Johan Herland 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
On Tue, May 7, 2013 at 3:29 AM, Junio C Hamano wrote:
> Johan Herland 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,
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 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
---
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.
