On Wednesday 2007 April 25, Junio C Hamano wrote: > >> 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@xxxxxxxxx - 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