Re: Pulling tags from git.git

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

 



Andreas Ericsson wrote:
A Large Angry SCM wrote:
Andreas Ericsson wrote:

Junio C Hamano wrote:

Andreas Ericsson <ae@xxxxxx> writes:


With the git or git+ssh protocol, tags will be autofollowed
when you do a pull (only signed tags, I think).  The
auto-following is done by detecting tags that are fetched,



Ah, you are correct.  We do not follow lightweight tags; I am
not sure if we should.


I'm fairly sure we shouldn't. The default update-hook prevents them (if enabled), and I can't for the life of me think of why anyone would want to distribute such tags.

OTOH, preventing unannotated tags from being pushed seems like a better way than to not have the ability to auto-follow those same tags. After all, it's better to discourage than to disallow.


Before you do this, please explain why unannotated tags are not useful, and so should not be allowed to be pushed.


Imagine Linus, getting his "please pull" emails and doing so only to find dozens of temporary tags fetched by the pull. Junio's patch (if I read it correctly) unconditionally fetches *ALL* tags reachable from the top of the commit-chain, which means there is no longer any way to keep temporary tags in a repo from which someone else will pull.

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

I for one riddle my repos with temporary tags whenever I'm trying something I'm not so sure of, or find an interesting bug or a design decision I'm not 100% sure of. Perhaps I should rather do this with branches, but imo branches are for doing work, whereas tags just mark a spot in the development so I easily can find them with gitk or some such.

I may be biased by the way we do things at work. In our workflow, all tags meant to be distributed have a short note in them which explains the rationale of the tag. For example, new versions have a very brief changelog that sales-people get on email (a blessing, that, since we devs no longer have to update feature-lists and such).

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.
-
: 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]