On Fri, 27 Aug 2010, Junio C Hamano wrote:
> Dave Olszewski <cxreg@xxxxxxxxx> writes:
>
> > Generally, tags are considered a write-once ref (or object), and updates
> > to them are the exception to the rule. This is evident from the
> > behavior of "git fetch", which will not update a tag it already has
> > unless --tags is specified, and from the --force option to "git tag".
>
> The title and what you describe later in your proposed log message do not
> match. This is about "push: disallow updating an existing tag by default"
> isn't it?
I don't see a major difference in meaning, since only fast-forwards are
allowed without --force, but you're right about my intent. I'm happy to
change the commit message.
> This proposes a big change in the policy, and I do not like it starting
> out as the new default to forbid people from doing something they have
> been allowed to do for a long time. I recall hearing some people auto
> tagging the latest version their autobuilder/tester tested successfully
> and updating the same tag nightly---your change will break their cron
> script, no?
>
> If you ship the feature disabled by default first, it will still allow
> people to take advantage of it by simply flipping the feature on, instead
> of having to install their own update hook. In a later version, if and
> when enough people agree that this should be on by default, we can do so
> at a version bump.
Yes that's true. I suspected based on the lack of any documentation or
tests promising such behavior, the inclination for git to want to
pretend that changed tags haven't changed, and the social stigma against
it, that this was a bug.
It's trivial for someone to update build software from "git push remote
tag" to "git push remote +tag" or "git push -f remote tag", but I can
understand your objection. It's the reason I didn't also add
receive.denyMovingTags to the default config for bare repositories.
It seems unlikely that many people are ever going to "flip on" this
feature; either they won't know about it (and for them, it should be
on), or they'll have a reason to move a tag, and want it off. That, and
my perception that this was unintentional behavior, is the reason I
patched it to be default.
However, If you still feel strongly about this, I can rework it to be
optional. Thanks for your feedback!
Dave
--
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