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

[Junio C Hamano <gitster@pobox.com>]

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?