Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> But if you have pushed things out (or others could just read your
> repository directly), then others will have already seen the old tag. In
> that case you can do one of two things:
> ...
> - The insane thing.
>
> You really want to call the new version "X" too, _even_though_ others
> have already seen the old one. So just use "git tag -f" again, as if
> you hadn't already published the old one.
>
> HOWEVER!
>
> Git does *not* (and in my very very strong opinion, MUST NOT!) change
> tags behind users back. So if somebody already got the old tag, doing a
> "git pull" on your tree shouldn't just make them overwrite the old one.
>
> And I really think that git does the right thing. If somebody got a
> release tag from you, you cannot just change the tag for them by updating
> your own one. I think this is a BIG security issue, in that people MUST be
> able to trust their tag-names. If I got a particular tag, NO WAY IN HELL
> must git just replace it for me because you happened to have a newer one!
>
> So if you really want to do the insane thing, you need to just fess up to
> it, and tell people that you messed up.
Confession time.
Although it is correct that the people who already saw the
original tag would not lose the tag object from their repository
when you publish a replacement tag, we have _always_ overwritten
the refs/tags/$tag to point at the new one, effectively losing
the original.
* 0a623e7c (Jul 5, 2005)
In this version "git fetch $repo tag v2.6.13" would have done just
echo "$head" >"$GIT_DIR/$destination"
without checking if it already existed.
* ae2da406 (Aug 22, 2005)
We started checking if the fetched/followed tag already existed
with this version. However, the result of the check was only
used to say "$tagname: updating with $new_sha1 from $old_sha1"
in the status message.
And after numerous code reorganizations of git-fetch throughout
its life, this logic has never been touched. This comment
around ll. 170 we currently have:
case "$1" in
refs/tags/*)
# Tags need not be pointing at commits so there
# is no way to guarantee "fast-forward" anyway.
was introduced with 853a3697 (Aug 20, 2005) and stayed there
ever since.
I think it is worth fixing this by tightening the rule as you
described, even with this late in the game for 1.5.0. The user
either needs to force it, or remove it beforehand.
diff --git a/git-fetch.sh b/git-fetch.sh
index 357cac2..1078016 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -169,14 +169,18 @@ update_local_ref () {
case "$1" in
refs/tags/*)
- # Tags need not be pointing at commits so there
- # is no way to guarantee "fast-forward" anyway.
+ # Tags should never be blindly overwritten without user's
+ # consent.
if test -n "$oldshort_"
then
if now_=$(git show-ref --hash "$1") && test "$now_" = "$2"
then
[ "$verbose" ] && echo >&2 "* $1: same as $3"
[ "$verbose" ] && echo >&2 " $label_: $newshort_" ||:
+ elif test -z "$force$single_force"
+ then
+ echo >&2 "* $1: refusing to update with $3"
+ false
else
echo >&2 "* $1: updating with $3"
echo >&2 " $label_: $newshort_"
-
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