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


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
More majordomo info at

Reply via email to