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

-----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 [off-list ref] writes:

quoted

From b1c2b07aa1f5db25ebdf190aa12ccb66a17f131a Mon Sep 17 00:00:00 2001
From: Daniel Knittl-Frank <redacted>
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