RE: [PATCH] builtin/fetch: print hash of deleted tag when updating

From: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Date: Sep 27, 2010, 11:37 UTC
Message-ID: <A612847CFE53224C91B23E3A5B48BAC749BFD33D90@xmail3.se.axis.com>
In-Reply-To: <7vsk0wmbcd.fsf@alter.siamese.dyndns.org>

Show 22 quoted lines

> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
> Behalf Of Junio C Hamano
> Sent: den 26 september 2010 23:42
> To: Knittl
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] builtin/fetch: print hash of deleted tag when
> updating
> 
> Knittl <knittl89@googlemail.com> writes:
> 
> > From b1c2b07aa1f5db25ebdf190aa12ccb66a17f131a Mon Sep 17 00:00:00 2001
> > From: Daniel Knittl-Frank <knittl89+git@googlemail.com>
> > Date: Sun, 26 Sep 2010 11:29:16 +0200
> > Subject: [PATCH] builtin/fetch: print hash of deleted tag when updating
> >
> > `git fetch --tags` will unconditionally update (and thus overwrite)
> > existing tags, which is especially annoying for annotated and signed
> > tags.
> 
> The first question is why s/he is running fetch with --tags if overwriting
> is unwelcome/annoying.

Maybe because the user is a git newbie who has just started to learn her first git commands and found --tags in the manual page, thinking "oh, nice, this will make sure I get all tags". Or because she added it to remote.<name>.tagopt without knowing that it would overwrite tags in this way.

> "--tags" is meant to be used when the auto-follow
> behaviour of normal fetch is not sufficient and the user actively wants to
> get the latest (potentially updated) ones;

If that (i.e., potentially updated) is the intention, it is not mentioned in the manual page for fetch. Further, reading "On Re-tagging" in the manual page for git tag, it says "Git does not (and it should not) change tags behind users back" (which I agree with) but it seems contrary to what --tags does...

Shouldn't this behavior of --tags require --force to keep in line with what is described in git tag's manual page? If not, a big warning sign is needed in the manual page description of --tags.

> would it be possible that you are solving a wrong problem?

Since git reflog does not support showing how a tag has changed, I think something like Daniel's patch is a good idea, as the alternative is to use git fsck and start digging...

//Peter