Jim Meyering wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. Well remember that all heads are simply references into the DAG, they are all labels. 'heads' you are allowed to move and change, commit to etc, but they are still just name -> sha1 mechanisms. If the merge is a ff then there is no work. You could always use 'reset' instead to move the branch to the right place in the DAG. > > 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* > immutable, with the default being it is immutable. -apw - 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