From: Jim Meyering <jim@meyering•net>
To: Johannes Schindelin <Johannes.Schindelin@gmx•de>
Cc: Junio C Hamano <junkio@cox•net>, git@vger•kernel.org
Subject: Re: can I remove or move a tag in a remote repository?
Date: Wed, 29 Nov 2006 11:55:28 +0100 [thread overview]
Message-ID: <87u00imsin.fsf@rho.meyering.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0611291040590.30004@wbgn013.biozentrum.uni-wuerzburg.de> (Johannes Schindelin's message of "Wed, 29 Nov 2006 10:54:10 +0100 (CET)")
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!
>> 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.
>> 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*
next prev parent reply other threads:[~2006-11-29 10:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-19 18:42 can I remove or move a tag in a remote repository? Jim Meyering
2006-11-19 18:54 ` Jakub Narebski
2006-11-28 11:08 ` Andreas Ericsson
2006-11-28 21:46 ` Junio C Hamano
2006-11-29 9:54 ` Johannes Schindelin
2006-11-29 10:55 ` Jim Meyering [this message]
2006-11-29 11:45 ` Johannes Schindelin
2006-11-29 13:46 ` Jakub Narebski
2006-11-29 11:47 ` Andy Whitcroft
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87u00imsin.fsf@rho.meyering.net \
--to=jim@meyering$(echo .)net \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=junkio@cox$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox