* Unify annotated and non-annotated tags @ 2017-11-10 10:58 anatoly techtonik 2017-11-11 1:46 ` Igor Djordjevic 0 siblings, 1 reply; 8+ messages in thread From: anatoly techtonik @ 2017-11-10 10:58 UTC (permalink / raw) To: git Hi, It is hard to work with Git tags, because on low level hash of non-annotated tag is pointing to commit, but hash for annotated tag is pointing to tag metadata. On low level that means that there is no way to get commit hash from tag in a single step. If tag is annotated, you need to find and parse ^{} string of show-ref, if not, then look for string without ^{}. So, why not just make all tags work the same so that every tag has its own hash and you need to dereference it in the same way to get commit hash? This way I could get all commit hashes with just: git show-ref --tags -d | grep "\^{}" or abandon ^{} completely and show commit hashes on -d: git show-ref --tags --dereference -- anatoly t. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unify annotated and non-annotated tags 2017-11-10 10:58 Unify annotated and non-annotated tags anatoly techtonik @ 2017-11-11 1:46 ` Igor Djordjevic 2017-11-11 2:06 ` Junio C Hamano 0 siblings, 1 reply; 8+ messages in thread From: Igor Djordjevic @ 2017-11-11 1:46 UTC (permalink / raw) To: anatoly techtonik, git Hi Anatoly, On 10/11/2017 11:58, anatoly techtonik wrote: > It is hard to work with Git tags, because on low level hash > of non-annotated tag is pointing to commit, but hash for > annotated tag is pointing to tag metadata. > > On low level that means that there is no way to get commit > hash from tag in a single step. If tag is annotated, you need > to find and parse ^{} string of show-ref, if not, then look for > string without ^{}. That is not quite true, as you can always dereference any tag (annotated or not) using "<tag>^0" notation, see git-rev-parse[1]: "As a special rule, <rev>^0 means the commit itself and is used when <rev> is the object name of a tag object that refers to a commit object." > So, why not just make all tags work the same so that every > tag has its own hash and you need to dereference it in the > same way to get commit hash? > > This way I could get all commit hashes with just: > > git show-ref --tags -d | grep "\^{}" > > or abandon ^{} completely and show commit hashes on -d: > > git show-ref --tags --dereference > Depending on what you would _exactly_ like to do, you could get all tagged commit hashes like this: git rev-list --tags --no-walk Note that each commit will be listed only once, even if more tags (annotated or not) point to it. If you would like to mimic output of "git show-ref", repeating commits for each tag pointing to it and showing full tag name as well, you could do something like this, for example: for tag in $(git for-each-ref --format="%(refname)" refs/tags) do printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag" done Hope that helps a bit. Regards, Buga [1] https://git-scm.com/docs/git-rev-parse#git-rev-parse-emltrevgtemegemHEADv1510em ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unify annotated and non-annotated tags 2017-11-11 1:46 ` Igor Djordjevic @ 2017-11-11 2:06 ` Junio C Hamano 2017-11-11 2:50 ` Igor Djordjevic ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Junio C Hamano @ 2017-11-11 2:06 UTC (permalink / raw) To: Igor Djordjevic; +Cc: anatoly techtonik, git Igor Djordjevic <igor.d.djordjevic@gmail.com> writes: > If you would like to mimic output of "git show-ref", repeating > commits for each tag pointing to it and showing full tag name as > well, you could do something like this, for example: > > for tag in $(git for-each-ref --format="%(refname)" refs/tags) > do > printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag" > done > > > Hope that helps a bit. If you use for-each-ref's --format option, you could do something like (pardon a long line): git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags without any loop, I would think. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unify annotated and non-annotated tags 2017-11-11 2:06 ` Junio C Hamano @ 2017-11-11 2:50 ` Igor Djordjevic 2017-11-23 7:31 ` anatoly techtonik 2017-12-23 13:33 ` anatoly techtonik 2 siblings, 0 replies; 8+ messages in thread From: Igor Djordjevic @ 2017-11-11 2:50 UTC (permalink / raw) To: Junio C Hamano; +Cc: anatoly techtonik, git On 11/11/2017 03:06, Junio C Hamano wrote: > Igor Djordjevic <igor.d.djordjevic@gmail.com> writes: > >> If you would like to mimic output of "git show-ref", repeating >> commits for each tag pointing to it and showing full tag name as >> well, you could do something like this, for example: >> >> for tag in $(git for-each-ref --format="%(refname)" refs/tags) >> do >> printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag" >> done >> >> >> Hope that helps a bit. > > If you use for-each-ref's --format option, you could do something > like (pardon a long line): > > git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags > > without any loop, I would think. ... and I did have a feeling it should be possible in a single Git command :P Thanks. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unify annotated and non-annotated tags 2017-11-11 2:06 ` Junio C Hamano 2017-11-11 2:50 ` Igor Djordjevic @ 2017-11-23 7:31 ` anatoly techtonik 2017-12-23 13:33 ` anatoly techtonik 2 siblings, 0 replies; 8+ messages in thread From: anatoly techtonik @ 2017-11-23 7:31 UTC (permalink / raw) To: Junio C Hamano; +Cc: Igor Djordjevic, git On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano <gitster@pobox.com> wrote: > Igor Djordjevic <igor.d.djordjevic@gmail.com> writes: > >> If you would like to mimic output of "git show-ref", repeating >> commits for each tag pointing to it and showing full tag name as >> well, you could do something like this, for example: >> >> for tag in $(git for-each-ref --format="%(refname)" refs/tags) >> do >> printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag" >> done >> >> >> Hope that helps a bit. > > If you use for-each-ref's --format option, you could do something > like (pardon a long line): > > git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags > > without any loop, I would think. Thanks. That helps. So my proposal is to get rid of non-annotated tags, so to get all tags with commits that they point to, one would use: git for-each-ref --format='%(*objectname) %(refname)' refs/tags For so-called non-annotated tags just leave the message empty. I don't see why anyone would need non-annotated tags though. -- anatoly t. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unify annotated and non-annotated tags 2017-11-11 2:06 ` Junio C Hamano 2017-11-11 2:50 ` Igor Djordjevic 2017-11-23 7:31 ` anatoly techtonik @ 2017-12-23 13:33 ` anatoly techtonik 2 siblings, 0 replies; 8+ messages in thread From: anatoly techtonik @ 2017-12-23 13:33 UTC (permalink / raw) To: Junio C Hamano; +Cc: Igor Djordjevic, Git Mailing List On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano <gitster@pobox.com> wrote: > Igor Djordjevic <igor.d.djordjevic@gmail.com> writes: > >> If you would like to mimic output of "git show-ref", repeating >> commits for each tag pointing to it and showing full tag name as >> well, you could do something like this, for example: >> >> for tag in $(git for-each-ref --format="%(refname)" refs/tags) >> do >> printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag" >> done >> >> >> Hope that helps a bit. > > If you use for-each-ref's --format option, you could do something > like (pardon a long line): > > git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags > > without any loop, I would think. This doesn't work with git 1.9.1 https://github.com/rtfd/readthedocs.org/pull/3441#issuecomment-353567756 When it was added? I searched through GitHub and docs, but can't find any historical records. -- anatoly t. ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <201711231458.vANEwUMK048049@elephants.elehost.com>]
* RE: Re: Unify annotated and non-annotated tags [not found] <201711231458.vANEwUMK048049@elephants.elehost.com> @ 2017-11-23 15:08 ` Randall S. Becker 2017-11-23 21:24 ` Thomas Braun 2017-11-24 9:52 ` anatoly techtonik 0 siblings, 2 replies; 8+ messages in thread From: Randall S. Becker @ 2017-11-23 15:08 UTC (permalink / raw) To: techtonik; +Cc: gitster, git, igor.d.djordjevic On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote >Subject: Re: Unify annotated and non-annotated tags >On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano <gitster@pobox.com> wrote: >> Igor Djordjevic <igor.d.djordjevic@gmail.com> writes: >> >>> If you would like to mimic output of "git show-ref", repeating >>> commits for each tag pointing to it and showing full tag name as >>> well, you could do something like this, for example: >>> >>> for tag in $(git for-each-ref --format="%(refname)" refs/tags) >>> do >>> printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag" >>> done >>> >>> >>> Hope that helps a bit. >> >> If you use for-each-ref's --format option, you could do something >> like (pardon a long line): >> >> git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags >> >> without any loop, I would think. >Thanks. That helps. >So my proposal is to get rid of non-annotated tags, so to get all >tags with commits that they point to, one would use: >git for-each-ref --format='%(*objectname) %(refname)' refs/tags> >For so-called non-annotated tags just leave the message empty. >I don't see why anyone would need non-annotated tags though. I have seen non-annotated tags used in automations (not necessarily well written ones) that create tags as a record of automation activity. I am not sure we should be writing off the concept of unannotated tags entirely. This may cause breakage based on existing expectations of how tags work at present. My take is that tags should include whodunnit, even if it's just the version of the automation being used, but I don't always get to have my wishes fulfilled. In essence, whatever behaviour a non-annotated tag has now may need to be emulated in future even if reconciliation happens. An option to preserve empty tag compatibility with pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of this usage based on a human memory page-fault and NDAs. Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000) -- In my real life, I talk too much. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unify annotated and non-annotated tags 2017-11-23 15:08 ` Randall S. Becker @ 2017-11-23 21:24 ` Thomas Braun 2017-11-24 9:52 ` anatoly techtonik 1 sibling, 0 replies; 8+ messages in thread From: Thomas Braun @ 2017-11-23 21:24 UTC (permalink / raw) To: Randall S. Becker, techtonik; +Cc: gitster, git, igor.d.djordjevic Am 23.11.2017 um 16:08 schrieb Randall S. Becker: [...] >> So my proposal is to get rid of non-annotated tags, so to get all >> tags with commits that they point to, one would use: >> git for-each-ref --format='%(*objectname) %(refname)' refs/tags> >> For so-called non-annotated tags just leave the message empty. >> I don't see why anyone would need non-annotated tags though. I'm using exclusively non-annotated tags. Why? Because that is the default of "git tag" and I also, until now, never needed more than giving a commit a "name". Many annotated tag messages just repeat the tag name itself, so the message seems quite redundant to me. Just my 2 cents, Thomas ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: Unify annotated and non-annotated tags 2017-11-23 15:08 ` Randall S. Becker 2017-11-23 21:24 ` Thomas Braun @ 2017-11-24 9:52 ` anatoly techtonik 2017-11-24 10:24 ` Ævar Arnfjörð Bjarmason 1 sibling, 1 reply; 8+ messages in thread From: anatoly techtonik @ 2017-11-24 9:52 UTC (permalink / raw) To: Randall S. Becker; +Cc: Junio C Hamano, git, Igor Djordjevic On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker <rsbecker@nexbridge.com> wrote: > On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote >>Subject: Re: Unify annotated and non-annotated tags >>On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano <gitster@pobox.com> wrote: >>> Igor Djordjevic <igor.d.djordjevic@gmail.com> writes: >>> >>>> If you would like to mimic output of "git show-ref", repeating >>>> commits for each tag pointing to it and showing full tag name as >>>> well, you could do something like this, for example: >>>> >>>> for tag in $(git for-each-ref --format="%(refname)" refs/tags) >>>> do >>>> printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag" >>>> done >>>> >>>> >>>> Hope that helps a bit. >>> >>> If you use for-each-ref's --format option, you could do something >>> like (pardon a long line): >>> >>> git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags >>> >>> without any loop, I would think. >>Thanks. That helps. >>So my proposal is to get rid of non-annotated tags, so to get all >>tags with commits that they point to, one would use: >>git for-each-ref --format='%(*objectname) %(refname)' refs/tags> >>For so-called non-annotated tags just leave the message empty. >>I don't see why anyone would need non-annotated tags though. > > I have seen non-annotated tags used in automations (not necessarily well written ones) that create tags as a record of automation activity. I am not sure we should be writing off the concept of unannotated tags entirely. This may cause breakage based on existing expectations of how tags work at present. My take is that tags should include whodunnit, even if it's just the version of the automation being used, but I don't always get to have my wishes fulfilled. In essence, whatever behaviour a non-annotated tag has now may need to be emulated in future even if reconciliation happens. An option to preserve empty tag compatibility with pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of this usage based on a human memory page-fault and NDAs. Are there any windows for backward compatibility breaks, or git is doomed to preserve it forever? Automation without support won't survive for long, and people who rely on that, like Chromium team, usually hard set the version used. -- anatoly t. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: Unify annotated and non-annotated tags 2017-11-24 9:52 ` anatoly techtonik @ 2017-11-24 10:24 ` Ævar Arnfjörð Bjarmason 2017-12-02 21:26 ` anatoly techtonik 0 siblings, 1 reply; 8+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2017-11-24 10:24 UTC (permalink / raw) To: anatoly techtonik Cc: Randall S. Becker, Junio C Hamano, Git Mailing List, Igor Djordjevic On Fri, Nov 24, 2017 at 10:52 AM, anatoly techtonik <techtonik@gmail.com> wrote: > On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker > <rsbecker@nexbridge.com> wrote: >> On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote >>>Subject: Re: Unify annotated and non-annotated tags >>>On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano <gitster@pobox.com> wrote: >>>> Igor Djordjevic <igor.d.djordjevic@gmail.com> writes: >>>> >>>>> If you would like to mimic output of "git show-ref", repeating >>>>> commits for each tag pointing to it and showing full tag name as >>>>> well, you could do something like this, for example: >>>>> >>>>> for tag in $(git for-each-ref --format="%(refname)" refs/tags) >>>>> do >>>>> printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag" >>>>> done >>>>> >>>>> >>>>> Hope that helps a bit. >>>> >>>> If you use for-each-ref's --format option, you could do something >>>> like (pardon a long line): >>>> >>>> git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags >>>> >>>> without any loop, I would think. >>>Thanks. That helps. >>>So my proposal is to get rid of non-annotated tags, so to get all >>>tags with commits that they point to, one would use: >>>git for-each-ref --format='%(*objectname) %(refname)' refs/tags> >>>For so-called non-annotated tags just leave the message empty. >>>I don't see why anyone would need non-annotated tags though. >> >> I have seen non-annotated tags used in automations (not necessarily well written ones) that create tags as a record of automation activity. I am not sure we should be writing off the concept of unannotated tags entirely. This may cause breakage based on existing expectations of how tags work at present. My take is that tags should include whodunnit, even if it's just the version of the automation being used, but I don't always get to have my wishes fulfilled. In essence, whatever behaviour a non-annotated tag has now may need to be emulated in future even if reconciliation happens. An option to preserve empty tag compatibility with pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of this usage based on a human memory page-fault and NDAs. > > Are there any windows for backward compatibility breaks, or git is > doomed to preserve it forever? > Automation without support won't survive for long, and people who rely > on that, like Chromium team, usually hard set the version used. Git is not doomed to preserve anything forever. We've gradually broken backwards compatibility for a few core things like these. However, just as a bystander reading this thread I haven't seen any compelling reason for why these should be removed. You initially had questions about how to extract info about them, which you got answers to. So what reasons remain for why they need to be removed? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: Unify annotated and non-annotated tags 2017-11-24 10:24 ` Ævar Arnfjörð Bjarmason @ 2017-12-02 21:26 ` anatoly techtonik 2017-12-03 5:54 ` Junio C Hamano 0 siblings, 1 reply; 8+ messages in thread From: anatoly techtonik @ 2017-12-02 21:26 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: Randall S. Becker, Junio C Hamano, Git Mailing List, Igor Djordjevic On Fri, Nov 24, 2017 at 1:24 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > On Fri, Nov 24, 2017 at 10:52 AM, anatoly techtonik <techtonik@gmail.com> wrote: >> On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker >> <rsbecker@nexbridge.com> wrote: >>> On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote >>>>Subject: Re: Unify annotated and non-annotated tags >>>>On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano <gitster@pobox.com> wrote: >>>>> Igor Djordjevic <igor.d.djordjevic@gmail.com> writes: >>>>> >>>>>> If you would like to mimic output of "git show-ref", repeating >>>>>> commits for each tag pointing to it and showing full tag name as >>>>>> well, you could do something like this, for example: >>>>>> >>>>>> for tag in $(git for-each-ref --format="%(refname)" refs/tags) >>>>>> do >>>>>> printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag" >>>>>> done >>>>>> >>>>>> >>>>>> Hope that helps a bit. >>>>> >>>>> If you use for-each-ref's --format option, you could do something >>>>> like (pardon a long line): >>>>> >>>>> git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags >>>>> >>>>> without any loop, I would think. >>>>Thanks. That helps. >>>>So my proposal is to get rid of non-annotated tags, so to get all >>>>tags with commits that they point to, one would use: >>>>git for-each-ref --format='%(*objectname) %(refname)' refs/tags> >>>>For so-called non-annotated tags just leave the message empty. >>>>I don't see why anyone would need non-annotated tags though. >>> >>> I have seen non-annotated tags used in automations (not necessarily well written ones) that create tags as a record of automation activity. I am not sure we should be writing off the concept of unannotated tags entirely. This may cause breakage based on existing expectations of how tags work at present. My take is that tags should include whodunnit, even if it's just the version of the automation being used, but I don't always get to have my wishes fulfilled. In essence, whatever behaviour a non-annotated tag has now may need to be emulated in future even if reconciliation happens. An option to preserve empty tag compatibility with pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of this usage based on a human memory page-fault and NDAs. >> >> Are there any windows for backward compatibility breaks, or git is >> doomed to preserve it forever? >> Automation without support won't survive for long, and people who rely >> on that, like Chromium team, usually hard set the version used. > > Git is not doomed to preserve anything forever. We've gradually broken > backwards compatibility for a few core things like these. > > However, just as a bystander reading this thread I haven't seen any > compelling reason for why these should be removed. You initially had > questions about how to extract info about them, which you got answers > to. > > So what reasons remain for why they need to be removed? To reduce complexity and prior knowledge when dealing with Git tags. For example, http://readthedocs.io/ site contains a lot of broken "Edit on GitHub" links, for example - http://git-memo.readthedocs.io/en/stable/ And it appeared that the reason for that is discrepancy between git annotated and non-annotated tags. The pull request that fixes the issue after it was researched and understood is simple https://github.com/rtfd/readthedocs.org/pull/3302 However, while looking through linked issues and PRs, one can try to imagine how many days it took for people to come up with the solution, which came from this thread. -- anatoly t. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unify annotated and non-annotated tags 2017-12-02 21:26 ` anatoly techtonik @ 2017-12-03 5:54 ` Junio C Hamano 0 siblings, 0 replies; 8+ messages in thread From: Junio C Hamano @ 2017-12-03 5:54 UTC (permalink / raw) To: anatoly techtonik Cc: Ævar Arnfjörð Bjarmason, Randall S. Becker, Git Mailing List, Igor Djordjevic anatoly techtonik <techtonik@gmail.com> writes: >> Git is not doomed to preserve anything forever. We've gradually broken >> backwards compatibility for a few core things like these. >> >> However, just as a bystander reading this thread I haven't seen any >> compelling reason for why these should be removed. You initially had >> questions about how to extract info about them, which you got answers >> to. >> >> So what reasons remain for why they need to be removed? > > To reduce complexity and prior knowledge when dealing with Git tags. Then you are barking up a wrong tree, I would have to say. If you do not think non-annotated tags are serving any good purpose in the context of _a_ project you are involved in and making your life miserable because some tags are and other tags are not annotated, suggest to _that_ project to refrain from using non-annotated tags. Projects that do use non-annotated tags have chosen to use them for reasons of their own. It may be that these tags could be annotated tags instead for some projects, and depending on their tooling there might be no downside in switching. Or they may have chosen to use non-annotated tags for reasons that you do not know. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-12-23 13:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-10 10:58 Unify annotated and non-annotated tags anatoly techtonik 2017-11-11 1:46 ` Igor Djordjevic 2017-11-11 2:06 ` Junio C Hamano 2017-11-11 2:50 ` Igor Djordjevic 2017-11-23 7:31 ` anatoly techtonik 2017-12-23 13:33 ` anatoly techtonik [not found] <201711231458.vANEwUMK048049@elephants.elehost.com> 2017-11-23 15:08 ` Randall S. Becker 2017-11-23 21:24 ` Thomas Braun 2017-11-24 9:52 ` anatoly techtonik 2017-11-24 10:24 ` Ævar Arnfjörð Bjarmason 2017-12-02 21:26 ` anatoly techtonik 2017-12-03 5:54 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).