Re: git-fetch and unannotated tags

From: Andy Parkins <andyparkins@gmail.com>
Date: Apr 26, 2007, 08:04 UTC
Message-ID: <200704260904.08447.andyparkins@gmail.com>
In-Reply-To: <7vfy6ow4my.fsf@assigned-by-dhcp.cox.net>

On Wednesday 2007 April 25, Junio C Hamano wrote:

Show 8 quoted lines

> >> You could even modify git-tag to create them for you with some
> >> appropriate switch ...
> >
> > Well yes, but that's the answer to everything isn't it?
>
> The answer to everything you want to change the current
> behaviour is to code something that implement that change.  What
> else is new?

Apologies - I wasn't saying that someone else should add features I want, I was saying that locally changing /my/ git-tag isn't very useful. I already get by with git, so when I post suggestions to the mailing list it's usually with respect to the wider context. In this case, patching git-tag to create refs/andys-private-tags/ doesn't seem like the right thing to do in mainline git :-)

> I suspect that if you look at what git-fetch.sh does in the
> paragraph that follows /^# automated tag following/, it probably
> is not that much change.  At that point,

 ... snip ...

That advice on the other hand is excellent.

Is this something that others would be in favour of? I'm soliciting for reasons why unannotated tags should be auto-followed?

> Take a look at exclude_existing() function in builtin-show-ref.c;
> your additional option to the command would say something like:

I'd be arguing for making not following unannotated tags the default, and then supply a switch to make them followed. Is that too painful? I think that's in keeping with the tradition that unannotated tags are, typically, not wanted in a central repository - the default update hook prevents it for example.

Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com