From: Junio C Hamano Date: Tue, 07 May 2013 01:29:11 GMT Subject: Re: [PATCH 2/7] t7900: Start testing usability of namespaced remote refs Message-ID: <7va9o7pogo.fsf@alter.siamese.dyndns.org> In-Reply-To: <1367711749-8812-3-git-send-email-johan@herland.net> 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