On Mon, Sep 17, 2012 at 11:39 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. > 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. -- 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