Re: Pulling tags from git.git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A Large Angry SCM wrote:

Why is a "pull" bothering with tags? A "fetch" yes, but not a pull.


A pull is a fetch + merge. I said pull because what little I know of Linus' workflow is the the emails he gets from susbsystem maintainers are called "pull requests".


Tags not meant to be distributed are unannotated, and unannotated tags are kept out of published repos which are always stored at a central server. Everybody synchronize to those central repos, so nobody pulls from each other. Perhaps this is how the kernel devs work too, but if it ever changes the update hook will no longer be able to safeguard from it and the, in my eyes, temporary tags will be distributed in a criss-crossing mesh so no-one will ever know where it came from or who created it or why. I.e. a Bad Thing.


The distinction here is not annotated tags or temporary tags but _local_ tags. _Your_ workflow conventions treat unannotated tags as local tags but declaring that unannotated tags can not be pushed is imposing _your_ conventions on other groups. Just as branch names, themselves, can be meaningful, so can tag names.


Yes, that's why I said it's better to discourage than to disallow. The default update-hook is disabled by default and there are comments aplenty to make it possible even for the most die-hard point-and-click monkey to be able to comment out the disallowing of unannotated tags.

--
Andreas Ericsson                   andreas.ericsson@xxxxxx
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
: 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]