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.
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
--
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
