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

On Mon, Sep 17, 2012 at 11:39 PM, Junio C Hamano [off-list ref] wrote:

Ralf Thielow [off-list ref] writes:

quoted

quoted

quoted

- 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.

IMO if a user uses "clone --single-branch --branch <tag>", then he/she
wants to have this tag only. Why should the next "git fetch" fetching
something different?
I read "treat them like detached HEAD" in the way that the resulting
repo is in a "detached HEAD" state.

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?

When using a tag in a different meaning than "tag this version and
do never change it", for example if someone uses a tag to describe
which revision of the project was lastly delivered to the customer, then
they could use a tag "delivered". After a new version was delivered,
someone changes this tag from "revx" to "revy". Having such a refspec,
you can fetch this tag and always get the delivered version.
This example is very theoretically.