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

From: Johan Herland <johan@herland.net>
Date: May 7, 2013, 21:52 UTC
Message-ID: <CALKQrgctyZGf2z+=+qjcW-s0uyVCqw01pv6X2NG+8yyC3FoTvQ@mail.gmail.com>
In-Reply-To: <7va9o7pogo.fsf@alter.siamese.dyndns.org>

On Tue, May 7, 2013 at 3:29 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> 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

Show 14 quoted lines

> 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