From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:21
Andreas Ericsson [off-list ref] 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.
We detect from ls-remote output if you have objects pointed by
remote tags (either signed or unsigned -- we cannot tell it from
ls-remote output) and fetch those tags that point at what we
have.
The auto following is done only when you are tracking remote
branches, BTW. Promiscuous fetch for immediate merging does not
follow tags.
Totally untested, so if somebody is interested, please test it,
and if it works, sign it off and bounce it back to me ;-).
-- >8 --
[PATCH] make "git fetch" follow unannotated tags as well.
---
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:21
Junio C Hamano wrote:
Andreas Ericsson [off-list ref] writes:
quoted
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: A Large Angry SCM <hidden> Date: 2016-06-15 22:42:21
Andreas Ericsson wrote:
Junio C Hamano wrote:
quoted
Andreas Ericsson [off-list ref] writes:
quoted
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.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:21
A Large Angry SCM wrote:
Andreas Ericsson wrote:
quoted
Junio C Hamano wrote:
quoted
Andreas Ericsson [off-list ref] writes:
quoted
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.
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: A Large Angry SCM <hidden> Date: 2016-06-15 22:42:21
Andreas Ericsson wrote:
A Large Angry SCM wrote:
quoted
Andreas Ericsson wrote:
quoted
Junio C Hamano wrote:
quoted
Andreas Ericsson [off-list ref] writes:
quoted
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.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:21
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".
quoted
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@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231