Jacob Keller <jacob.keller@xxxxxxxxx> writes: > 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. 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, 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.
