> In short, if you truly want to see "separate hierarchy per remote",
> you should consider how you can reliably implement an equivalent of
> "git branch --list --remote"; a design that does not allow it is a
> failure.
>
> A better solution with longer lifetime would probably be to use
>
>         refs/remotes/$remoteName/{heads,tags,...}/
>
> when core.useTotallySeparateRemote configuration exists (and
> eventually at Git 3.0 make the layout the default).  It would
> involve changes in the refname look-up rules, but it would not have
> to pollute refs/ namespace like the refs/remoteTags/ half-ground
> design, which would require us to add refs/remoteNotes/ and friends,
> who knows how many more we would end up having to support if we go
> that route.

I've used submodules a little bit and in some sense it seems to
already implement
core.useTotallySeparateRemote. So from my perspective trying to make this change
significantly different this isn't worth the effort and I'm not sure I
have the expertise
to do it well.

Is there a roadmap and or timeline for Git 3.0?

Reply via email to