On Tue, May 1, 2018 at 4:24 PM, Junio C Hamano [off-list ref] wrote:

Jacob Keller [off-list ref] writes:

quoted

I also agree, I'd prefer if we aim for the mapping to be something
which works for all refs in the future, even if such support isn't
added now, which is why i've proposed using "refs/remote/<name>/" so
that a tag would go from

refs/tags/v1.7

to

refs/remote/<name>/tags/v1.7

Ideally, we could work to update "refs/remotes/<name>" to go to
"refs/remote/<name>/heads" as well.

This is *not* imcompatible with having refs/remote-tags/* as an
interim solution.

Sure. I'm just proposing that we pick a name that all the refs can move to now.

We'll have to support refs/remotes/<name>/<branch> anyway long after
we start using refs/remote/<name>/heads/<branch> by (1) switching
the fetch refspecs newer "git clone" writes to the latter format,

Ofcourse we'll have to support this, and i didn't mean to imply we wouldn't.

I was just hoping to avoid having even more places to check in the future.

and (2) extending the dwim table to try both formats.  Having Wink's
solution as an interim step adds one more entry to (2) but the
machinery is already there.  And it does not change (1), either.

Sure, we could. And yes, we have to do (1), which means we have to do
(2) anyways. But we can still pick something which is more easily
expandable than refs/remotes/<name> was.

Thanks,
Jake