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 Herland, <jo...@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

Reply via email to