Re: can I remove or move a tag in a remote repository?

From: Jim Meyering <jim@meyering.net>
Date: Nov 29, 2006, 10:55 UTC
Message-ID: <87u00imsin.fsf@rho.meyering.net>
In-Reply-To: <Pine.LNX.4.63.0611291040590.30004@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> On Tue, 28 Nov 2006, Junio C Hamano wrote:

...

>> I think this is due to overeager receive.denyNonFastForwards
>> configuration setting at the repository you are pushing into.

Junio, thank you for following up on this!

Show 14 quoted lines

>> I _think_ what receive-pack does in this case is totally wrong.
>> It should either:
>>
>>  (1) deny overwriting existing tags -- tags are meant to be
>>      immutable so it should not allow them to be "updated"
>>      regardless of fast-forwardness, or
>>
>>  (2) allow overwriting things under refs/tags/ without any
>>      fast-forward checking.  After all, a tag could point at a
>>      tree or a blob, and there is no fast-forwardness among
>>      trees.
>>
>> The client side check in "git fetch" takes the latter viewpoint,
>> and I think we should be consistent with it.

Show 10 quoted lines

>> Johannes, what do you think?  Does the following patch look sane
>> to you?
>
> It does if you agree that (2) is correct.
>
> But I don't agree. cvs-head really should be a head IMHO, not a tag,
> because cvs-head really tracks a branch.
>
> I also think that git-fetch silently updating tags is wrong. Rather, it
> should warn that the tags are different. But I've been wrong before.

AFAIK, no one wants git-fetch to update tags _silently_. I expected it give a diagnostic and fail by default -- and it already does that. Pushing moved tags is serious business. I was hoping to be able to use --force to override that fail-safe.

My goal is to maintain a symbolic reference "cvs-head" that points to the newest git trunk node that's been mirrored to a CVS repository. Without even considering any other option, I chose to use a lightweight tag for that purpose, since I have a conceptual view that it's a label I can move from one referent to another. It strikes me as counter-intuitive to use a temporary git "branch" that way. Would that even work, removing it and recreating it all the time? Hmm.. or maybe you mean to create the branch once and then to merge from the trunk repeatedly. That seems like unnecessary work, when all I want is a movable label.

I admit that I like the idea of release tags being immutable, but even there, it's happened that I've made-but-not-published a release, then realized that it wasn't quite complete. I was glad to be able to go back and re-tag after making corrections.

I wouldn't mind having a way to specify that a pushed tag is *not*