Re: [PATCH 2/7] t7900: Start testing usability of namespaced remote refs

[Johan Herland <johan@herland.net>]

On Tue, May 7, 2013 at 3:29 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Johan Herland <johan@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, <johan@herland.net>
www.herland.net