On Tue, May 1, 2018 at 4:24 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.kel...@gmail.com> 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.
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
