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
