On Mon, Sep 17, 2012 at 11:39 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Ralf Thielow <ralf.thie...@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.

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to