Ralf Thielow <ralf.thielow@xxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html