Re: [PATCHv5] clone --single: limit the fetch refspec to fetched branch

> Ralf Thielow <ralf.thielow@gmail.com> writes:
>
>>>> - install correct refspec if the value of --branch is a tag (test added)
>>>
>>> What is the definition of "correct"?  I see the documentation says
>>> "--branch can also take tags and treat them like detached HEAD", and
>>> even though I _think_ allowing tags was a huge mistake, if we claim
>>> we treat it like detached HEAD, we should do the same when coming up
>>> with the refspec used for the follow-up "fetch".
>>>
>>
>> This patch would install the refspec "+refs/tags/v1.7.10:refs/tags/v1.7.10",
>> so we would do the same with the follow-up "fetch", not?
>> This can be seen as "it's not a bug, it's a feature". Why not cloning a
>> tag of a repo if someone just want to build a tag without having anything else.
>
> Even though I did say I thought allowing tags was a huge mistake, I
> was not suggesting to break existing users by making such a clone
> into an error.
>
> But the main point of the discussion is what should happen upon the
> next "git fetch" in the repository, no?  Shouldn't the refspec be
> the same as the case where you "clone --single" a repository whose
> HEAD is detached at v1.7.10 in that example, instead of saying
> "fetch the same tag over and over"?  After all that is the way I
> expect that most people would read "treat them line detached HEAD"
> in the documentation.  Subsequent "git fetch" would fetch from the
> HEAD of the upstream just like a clone from a repository with a
> detached HEAD.
>

> The above is *not* a rhetorical question; I just do not think of a
> sensible reason why we want a refspec that says "keep updating the
> v1.7.10 tag, as it might change on the other end, and do not bother
> what other things that happen in that upstream repository".  What
> sensible workflow would benefit from such a refspec?
>
>