From: Jacob Keller <jacob.keller@gmail.com>
Date: Wed, 02 May 2018 00:08:06 GMT
Subject: Re: [RFC PATCH v4 0/3] Optional sub hierarchy for remote tags
Message-ID: <CA+P7+xrPkMkt4zULuhEY-H9QHq8QE3gbkY-i+_HFk04W=vS29w@mail.gmail.com>
In-Reply-To: <xmqqh8nrx8m1.fsf@gitster-ct.c.googlers.com>

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