User has access to subset list of project tags

[Alon Bar-Lev]

Hi,

I have a very strange issue with Gerrit and a specific user.

For some reason a specific user cannot see a specific tag in a project.

The tag is not visible for a specific user in Gerrit user interface nor in `git ls-remote` output.

Other users can see the tag.

We have no specific tag access settings, the tags are quite standard... see the following, the problematic tag is v1.1.2, the rest are visible.

```

 git ls-remote | grep tags
d7aceeeb1b45396d48037ab5db07c55c24e28ce0 refs/tags/v1.0.0
c4a424ac7ae9301401bdd23a3b89f8cc9ab19a0c refs/tags/v1.0.1
f8d5a96e14d3ccf67310b262a64c9aadfe950f51 refs/tags/v1.1.0
4d8391da08d437a37a8021b31122d86cad5dda1d refs/tags/v1.1.1
70cb277cae6110a5b50833bf23717a2ad9680406 refs/tags/v1.1.2     <=====
```

The tag was created via the web user interface.

It is not an index issue as I did rebuild all indexes.

It occured on 3.12.1 and also 3.12.2.

We are using ssh protocol, but it seems unrelated as the web user interface and the git show the same result.

Any clue how to debug this?

Thanks,

Alon

[Alon Bar-Lev]

Hi,

I solved this by adding Read permission at  `refs/*` to Project Owners.

Now all tags are visible.

I am not sure why it should be added and what is special about this specific tag that was hidden.

Thanks,

Alon

[Nasser Grainawi]

On Wed, Aug 27, 2025 at 10:30 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hi,

I solved this by adding Read permission at  `refs/*` to Project Owners.

Now all tags are visible.

I am not sure why it should be added and what is special about this specific tag that was hidden.

Visibility on tags is determined by which branches are visible. So usually this scenario happens when these tags point to commits that are either 1) only on branches the user cannot see or 2) not on any branch (only reachable from the tag).

Nasser

 

Thanks,

Alon

On Wed, 27 Aug 2025 at 19:00, Alon Bar-Lev <alon....@gmail.com> wrote:

Hi,

I have a very strange issue with Gerrit and a specific user.

For some reason a specific user cannot see a specific tag in a project.

The tag is not visible for a specific user in Gerrit user interface nor in `git ls-remote` output.

Other users can see the tag.

We have no specific tag access settings, the tags are quite standard... see the following, the problematic tag is v1.1.2, the rest are visible.

```

 git ls-remote | grep tags
d7aceeeb1b45396d48037ab5db07c55c24e28ce0 refs/tags/v1.0.0
c4a424ac7ae9301401bdd23a3b89f8cc9ab19a0c refs/tags/v1.0.1
f8d5a96e14d3ccf67310b262a64c9aadfe950f51 refs/tags/v1.1.0
4d8391da08d437a37a8021b31122d86cad5dda1d refs/tags/v1.1.1
70cb277cae6110a5b50833bf23717a2ad9680406 refs/tags/v1.1.2     <=====
```

The tag was created via the web user interface.

It is not an index issue as I did rebuild all indexes.

It occured on 3.12.1 and also 3.12.2.

We are using ssh protocol, but it seems unrelated as the web user interface and the git show the same result.

Any clue how to debug this?

Thanks,

Alon

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/CAOazyz0%2B2tbHDRr%2BbZAcaxqqYRz83Zo-aGmT%2B_W0f%2B5gTrW0rA%40mail.gmail.com.

[Alon Bar-Lev]

On Thu, 28 Aug 2025 at 00:14, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Wed, Aug 27, 2025 at 10:30 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hi,

I solved this by adding Read permission at  `refs/*` to Project Owners.

Now all tags are visible.

I am not sure why it should be added and what is special about this specific tag that was hidden.

Visibility on tags is determined by which branches are visible. So usually this scenario happens when these tags point to commits that are either 1) only on branches the user cannot see or 2) not on any branch (only reachable from the tag).

Hello Nasser,

Thank you for your response.

I also thought that the problem is a tag that is not reachable from any head, but this is not the case.

The user can see all the branches.

The tag is in the history of a branch.

commit 0da744e6994a737945f036a996d3408172d3f265 (origin/stable-1.1)
commit 70cb277cae6110a5b50833bf23717a2ad9680406 (tag: v1.1.2)

The interesting behavior is that I added Read permission at  `refs/*` to Project Owners and it resolved this specific tag that is missing for this user.

Thanks,

Alon

[Nasser Grainawi]

On Wed, Aug 27, 2025 at 3:30 PM Alon Bar-Lev <alon....@gmail.com> wrote:

On Thu, 28 Aug 2025 at 00:14, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Wed, Aug 27, 2025 at 10:30 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hi,

I solved this by adding Read permission at  `refs/*` to Project Owners.

Now all tags are visible.

I am not sure why it should be added and what is special about this specific tag that was hidden.

Visibility on tags is determined by which branches are visible. So usually this scenario happens when these tags point to commits that are either 1) only on branches the user cannot see or 2) not on any branch (only reachable from the tag).

Hello Nasser,

Thank you for your response.

I also thought that the problem is a tag that is not reachable from any head, but this is not the case.

The user can see all the branches.

The tag is in the history of a branch.

Hmm. Might be a bug or some other issue. Anything in the error logs? You could try using the checkAccess REST API https://gerrit-review.googlesource.com/Documentation/rest-api-projects.html#check-access

 

commit 0da744e6994a737945f036a996d3408172d3f265 (origin/stable-1.1)
commit 70cb277cae6110a5b50833bf23717a2ad9680406 (tag: v1.1.2)

The interesting behavior is that I added Read permission at  `refs/*` to Project Owners and it resolved this specific tag that is missing for this user.

That's because the default value for the config auth.skipFullRefEvaluationIfAllRefsAreVisible means READ on `refs/*` activates a special behavior that allows reading all refs.

[Vitaliy L.]

Hi

среда, 27 августа 2025 г. в 19:01:12 UTC+3, Alon Bar-Lev

We have no specific tag access settings, the tags are quite standard... see the following, the problematic tag is v1.1.2, the rest are visible.

... 

The tag was created via the web user interface.

Check if created tag lightweight or annotated, Gerrit might treat different types differently.

[Alon Bar-Lev]

On Thu, 28 Aug 2025 at 02:37, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Wed, Aug 27, 2025 at 3:30 PM Alon Bar-Lev <alon....@gmail.com> wrote:

On Thu, 28 Aug 2025 at 00:14, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Wed, Aug 27, 2025 at 10:30 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hi,

I solved this by adding Read permission at  `refs/*` to Project Owners.

Now all tags are visible.

I am not sure why it should be added and what is special about this specific tag that was hidden.

Visibility on tags is determined by which branches are visible. So usually this scenario happens when these tags point to commits that are either 1) only on branches the user cannot see or 2) not on any branch (only reachable from the tag).

Hello Nasser,

Thank you for your response.

I also thought that the problem is a tag that is not reachable from any head, but this is not the case.

The user can see all the branches.

The tag is in the history of a branch.

Hmm. Might be a bug or some other issue. Anything in the error logs? You could try using the checkAccess REST API https://gerrit-review.googlesource.com/Documentation/rest-api-projects.html#check-access

 

In the log I see:

---

[2025-08-28T06:00:22.759Z] [SSH git-upload-pack /project1 (user1)] INFO  com.google.gerrit.server.permissions.DefaultRefFilter : Performing visibility check for all refs. This can be expensive. [CONTEXT ratelimit_period="1 SECONDS" skipped=1 TRACE_ID="1756360822756-38d8c299" project="project1" request="GIT_UPLOAD" ]

---

There is no difference between the checkAccess debug_logs, however, for the v1.1.1 it is a success ("status":200) and for the v1.1.2 it is a failure with message "user 1000006 lacks permission null for refs/tags/v1.1.2 in project project1".

---

{
  "message": "user 1000006 lacks permission null for refs/tags/v1.1.2 in project project1",
  "status": 403,
  "debug_logs": [
    "\\u0027user1\\u0027 can perform \\u0027owner\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027 (allowed for group \\u002707827793233ac88881c8194cd150ed4d1927024b\\u0027 by rule \\u0027group CTO Embedded\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/master\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/stable-1.0\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/stable-1.1\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/notes/review\\u0027"
  ]
}

---

[Alon Bar-Lev]

Hi,

The tags are lightweight tags.

Thanks,

Alon

[Alon Bar-Lev]

Hello Nasser,

Have you reviewed the log? Have any clue what happens?

The two branch logs look identical but one fails.

Thanks,

Alon

[Björn Pedersen]

From the  docs [1]: 

• if you push a lightweight tag without the access right 'Create Reference' for the reference name refs/tags/*

• if you push a tag with somebody else as tagger and you don’t have the 'Forge Committer' access right for the reference name refs/tags/*

=> Check if the tag was created by a user without  the required permissions...

[1] https://gerrit-review.googlesource.com/Documentation/error-prohibited-by-gerrit.html

[Alon Bar-Lev]

On Thu, 4 Sept 2025 at 15:29, 'Björn Pedersen' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

From the  docs [1]: 

• if you push a lightweight tag without the access right 'Create Reference' for the reference name refs/tags/*

• if you push a tag with somebody else as tagger and you don’t have the 'Forge Committer' access right for the reference name refs/tags/*

=> Check if the tag was created by a user without  the required permissions...

[1] https://gerrit-review.googlesource.com/Documentation/error-prohibited-by-gerrit.html

Hello,

The tag was created from the UI so I do not think it could have been created without permission.

I double checked now and the default in "All-Projects" is to have "Create Reference" for "Project Owners" which the user belongs to.

This means that the user has permissions and the tag was not created by someone else.

In any case, even if we reach this situation, we should be able to query something to understand what is the current state, the checkAccess was promising but showed no reason.

Thanks,

Alon

 

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/b0780168-13fc-4bb5-bacd-c16b802298b6n%40googlegroups.com.

[Nasser Grainawi]

On Thu, Sep 4, 2025 at 2:22 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hello Nasser,

Have you reviewed the log? Have any clue what happens?

The two branch logs look identical but one fails.

Sorry, I missed replying to your earlier email. I'm confused about the "lacks permission null" part of the response message. What did your REST API request look like?

[Alon Bar-Lev]

On Thu, 4 Sept 2025 at 20:37, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Thu, Sep 4, 2025 at 2:22 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hello Nasser,

Have you reviewed the log? Have any clue what happens?

The two branch logs look identical but one fails.

Sorry, I missed replying to your earlier email. I'm confused about the "lacks permission null" part of the response message. What did your REST API request look like?

 

Hi,

Please notice that only the problematic tag produces this message.

As this is GET I just use browser, login to gerrit, then put the following in the URL:

With one of the good tags:

https://gerrit/projects/project1/check.access?account=1000006&ref=refs%2Ftags%2Fv1.1.1

{"status":200,"debug_logs":...}

With the problematic tag:

https://gerrit/projects/project1/check.access?account=1000006&ref=refs%2Ftags%2Fv1.1.2

{"message":"user 1000006 lacks permission null for refs/tags/v1.1.2 in project project1","status":403,"debug_logs":...}

The debug_logs are identical in both cases, I pasted it in the previous message.

Should I perform the call differently?

Thanks,

Alon

[Alon Bar-Lev]

On Thu, 4 Sept 2025 at 21:57, Alon Bar-Lev <alon....@gmail.com> wrote:

On Thu, 4 Sept 2025 at 20:37, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Thu, Sep 4, 2025 at 2:22 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hello Nasser,

Have you reviewed the log? Have any clue what happens?

The two branch logs look identical but one fails.

Sorry, I missed replying to your earlier email. I'm confused about the "lacks permission null" part of the response message. What did your REST API request look like?

 

Hi,

Please notice that only the problematic tag produces this message.

As this is GET I just use browser, login to gerrit, then put the following in the URL:

With one of the good tags:

https://gerrit/projects/project1/check.access?account=1000006&ref=refs%2Ftags%2Fv1.1.1

{"status":200,"debug_logs":...}

With the problematic tag:

https://gerrit/projects/project1/check.access?account=1000006&ref=refs%2Ftags%2Fv1.1.2

{"message":"user 1000006 lacks permission null for refs/tags/v1.1.2 in project project1","status":403,"debug_logs":...}

The debug_logs are identical in both cases, I pasted it in the previous message.

Should I perform the call differently?

When I try to use non-existence tag, I get the same message but much shorter debug_logs it is the prefix of the debug_logs when tag exists. I guess you can test that you get this message for any non-existence tag in your environment as well.

https://gerrit/projects/project1/check.access?account=1000006&ref=refs%2Ftags%2Fv1.1.10

{
  "message": "user 1000006 lacks permission null for refs/tags/v1.1.10 in project project1",

  "status": 403,
  "debug_logs": [
    "\\u0027user1\\u0027 can perform \\u0027owner\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027 (allowed for group \\u002707827793233ac88881c8194cd150ed4d1927024b\\u0027 by rule \\u0027group CTO Embedded\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027"

  ]
}

[Alon Bar-Lev]

Hello Nasser and All,

It happened again for a different user.

A user can access a partial list of tags, in this case it looks like the user can access annotated tags and not simple tags.

$ git ls-remote | grep refs/tags/

89fe9eb380397897df145219ea247f9d76d4ccf3 refs/tags/v0.3.1
5b18e2e7db63a725aa9dc8463a67a90293e68507 refs/tags/v0.3.1^{}
78bdd2742169d2b281bd7cd0455f4301d580c767 refs/tags/v0.3.2      <--- user cannot see this one

I checked and te tag is part of a valid branch:

$ git branch --contains v0.3.2
* stable-0.3

Check access output is attached.

What data can I provide to assist in understanding why?

What special in tags? specifically what special in simple tags?

Thanks,

Alon

---

https://gerrit/projects/project1/check.access?account=1000013&ref=refs%2Ftags%2Fv0.3.2
[I replaced unicode chars for readability]
{
  "message": "user 1000013 lacks permission null for refs/tags/v0.3.2 in project project1",
  "status": 403,
  "debug_logs": [
    "'user1' can perform 'owner' with force=false on project 'project1' for ref 'refs/*' (allowed for group 'user:user1' by rule 'group user/user1 (user1)')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/meta/version' (allowed for group 'global:Anonymous-Users' by rule 'group Anonymous Users')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/meta/config' (allowed for group 'global:Project-Owners' by rule 'group Project Owners')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/tags/*' (allowed for group 'global:Project-Owners' by rule 'group Project Owners')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/heads/*' (allowed for group '3ef1c33f02fd4e4b90b1d03f103c009c57fe68e0' by rule 'group group1')",
    "'user1' cannot perform 'read' with force=false on project 'project1' for ref 'refs/*'",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/meta/version' (allowed for group 'global:Anonymous-Users' by rule 'group Anonymous Users')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/meta/config' (allowed for group 'global:Project-Owners' by rule 'group Project Owners')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/tags/*' (allowed for group 'global:Project-Owners' by rule 'group Project Owners')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/heads/*' (allowed for group '3ef1c33f02fd4e4b90b1d03f103c009c57fe68e0' by rule 'group group1')",
    "'user1' cannot perform 'read' with force=false on project 'project1' for ref 'refs/*'",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/meta/version' (allowed for group 'global:Anonymous-Users' by rule 'group Anonymous Users')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/meta/config' (allowed for group 'global:Project-Owners' by rule 'group Project Owners')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/tags/*' (allowed for group 'global:Project-Owners' by rule 'group Project Owners')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/heads/*' (allowed for group '3ef1c33f02fd4e4b90b1d03f103c009c57fe68e0' by rule 'group group1')",
    "'user1' cannot perform 'read' with force=false on project 'project1' for ref 'refs/*'",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/meta/version' (allowed for group 'global:Anonymous-Users' by rule 'group Anonymous Users')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/meta/config' (allowed for group 'global:Project-Owners' by rule 'group Project Owners')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/tags/*' (allowed for group 'global:Project-Owners' by rule 'group Project Owners')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/heads/*' (allowed for group '3ef1c33f02fd4e4b90b1d03f103c009c57fe68e0' by rule 'group group1')",
    "'user1' cannot perform 'read' with force=false on project 'project1' for ref 'refs/*'",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/meta/version' (allowed for group 'global:Anonymous-Users' by rule 'group Anonymous Users')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/meta/config' (allowed for group 'global:Project-Owners' by rule 'group Project Owners')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/tags/*' (allowed for group 'global:Project-Owners' by rule 'group Project Owners')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/heads/*' (allowed for group '3ef1c33f02fd4e4b90b1d03f103c009c57fe68e0' by rule 'group group1')",
    "'user1' cannot perform 'read' with force=false on project 'project1' for ref 'refs/*'",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/heads/master' (allowed for group '3ef1c33f02fd4e4b90b1d03f103c009c57fe68e0' by rule 'group group1')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/heads/stable-0.1' (allowed for group '3ef1c33f02fd4e4b90b1d03f103c009c57fe68e0' by rule 'group group1')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/heads/stable-0.2' (allowed for group '3ef1c33f02fd4e4b90b1d03f103c009c57fe68e0' by rule 'group group1')",
    "'user1' can perform 'read' with force=false on project 'project1' for ref 'refs/heads/stable-0.3' (allowed for group '3ef1c33f02fd4e4b90b1d03f103c009c57fe68e0' by rule 'group group1')",
    "'user1' cannot perform 'read' with force=false on project 'project1' for ref 'refs/notes/review'"
  ]
}

[Alon Bar-Lev]

Hi,

Has anyone encountered an issue in which tags are partially visible to users and succeeded to solve this without allowing refs/*?

I have multiple examples of regular users who see only a subset of tags, I've provided all the information I could find and also the helper check.access API, which should be helpful for debugging.

I could not find what is wrong in the configuration and what is the difference between the use cases, it seems that the simple tags are more subject to be hidden.

Thanks,

Alon

[Kenyon Ralph]

On Monday, December 29, 2025 at 11:05:03 PM UTC-8 Alon Bar-Lev wrote:

Hi,

Has anyone encountered an issue in which tags are partially visible to users and succeeded to solve this without allowing refs/*?

I don't have a good answer, but I also have encountered this issue on Gerrit 3.11.1. My solution was to allow Read on refs/*. In my case, I could tell from ls-user-refs that the user could read the branch that contains the commit the tag points to, but still he could not see the tag. I posted about it on the Gerrit Discord on June 5, 2025: https://discord.com/channels/775374026587373568/775374026587373571/1380321249422737571

[Luca Milanesio]

> On 6 Jan 2026, at 00:25, 'Kenyon Ralph' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
>
> On Monday, December 29, 2025 at 11:05:03 PM UTC-8 Alon Bar-Lev wrote:
> Hi,
>
> Has anyone encountered an issue in which tags are partially visible to users and succeeded to solve this without allowing refs/*?
>
> I don't have a good answer, but I also have encountered this issue on Gerrit 3.11.1. My solution was to allow Read on refs/*. In my case, I could tell from ls-user-refs that the user could read the branch that contains the commit the tag points to, but still he could not see the tag. I posted about it on the Gerrit Discord on June 5, 2025: https://discord.com/channels/775374026587373568/775374026587373571/1380321249422737571

The visibility of tags is a lot more complex than the visibility on any other refs.
Instead of just maching the ref name, it is also based on reachability by visible branches.

Have you tried creating a branch that points to the SHA1 of the tag and it is visible by the user?
If that shows the tags, then it means that you have a reachability issue.

HTH

Luca.

> I have multiple examples of regular users who see only a subset of tags, I've provided all the information I could find and also the helper check.access API, which should be helpful for debugging.
>
> I could not find what is wrong in the configuration and what is the difference between the use cases, it seems that the simple tags are more subject to be hidden.
> Thanks,
> Alon
>

> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/e4bc9ae7-b126-45a0-836a-9612401ce59an%40googlegroups.com.

[Alon Bar-Lev]

On Tue, 6 Jan 2026 at 02:25, 'Kenyon Ralph' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

On Monday, December 29, 2025 at 11:05:03 PM UTC-8 Alon Bar-Lev wrote:

Hi,

Has anyone encountered an issue in which tags are partially visible to users and succeeded to solve this without allowing refs/*?

I don't have a good answer, but I also have encountered this issue on Gerrit 3.11.1. My solution was to allow Read on refs/*. In my case, I could tell from ls-user-refs that the user could read the branch that contains the commit the tag points to, but still he could not see the tag. I posted about it on the Gerrit Discord on June 5, 2025: https://discord.com/channels/775374026587373568/775374026587373571/1380321249422737571

Thank you Ralph, I am aware of this, @Nasser Grainawi wrote that having refs/* is somekind of bypass to permissions, while I would like to avoid the bypass and understand the issue.

 

 

I have multiple examples of regular users who see only a subset of tags, I've provided all the information I could find and also the helper check.access API, which should be helpful for debugging.

I could not find what is wrong in the configuration and what is the difference between the use cases, it seems that the simple tags are more subject to be hidden.

 

Thanks,

Alon

--

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/e4bc9ae7-b126-45a0-836a-9612401ce59an%40googlegroups.com.

[Alon Bar-Lev]

On Tue, 6 Jan 2026 at 08:03, Luca Milanesio <luca.mi...@gmail.com> wrote:

> On 6 Jan 2026, at 00:25, 'Kenyon Ralph' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
>
> On Monday, December 29, 2025 at 11:05:03 PM UTC-8 Alon Bar-Lev wrote:
> Hi,
>
> Has anyone encountered an issue in which tags are partially visible to users and succeeded to solve this without allowing refs/*?
>
> I don't have a good answer, but I also have encountered this issue on Gerrit 3.11.1. My solution was to allow Read on refs/*. In my case, I could tell from ls-user-refs that the user could read the branch that contains the commit the tag points to, but still he could not see the tag. I posted about it on the Gerrit Discord on June 5, 2025: https://discord.com/channels/775374026587373568/775374026587373571/1380321249422737571


The visibility of tags is a lot more complex than the visibility on any other refs.
Instead of just maching the ref name, it is also based on reachability by visible branches.

Have you tried creating a branch that points to the SHA1 of the tag and it is visible by the user?
If that shows the tags, then it means that you have a reachability issue.

Hi Luca,

Thank you for the suggestion, after creating a branch out of the tag v0.3.2 with name stable-alon, the user sees the tag.

I do not understand the reachability issue.

The branch stable-0.3 is visible to the user he actively works on this branch.

The branch does include the v0.3.2 simple tag, while he can see v0.3.1 and v0.3.0 which are annotated tags.

$ git log --oneline origin/stable-0.3
ee7cca8 (origin/stable-0.3) release: prepare for 0.3.3
78bdd27 (tag: v0.3.2) bugfix: filtering duplicate
0ef11e9 release: prepare for 0.3.2
5b18e2e (tag: v0.3.1) bugfix: support
d0e8d8b release: Prepare for 0.3.1
a4bb47d (tag: v0.3.0) bugfix: keep enough points

$ git rev-parse v0.3.2
78bdd2742169d2b281bd7cd0455f4301d580c767
$ git branch -a --contains v0.3.2
  remotes/origin/stable-0.3
$ git branch -a --contains 78bdd2742169d2b281bd7cd0455f4301d580c767
  remotes/origin/stable-0.3

Before adding the branch:

bf49a0b1c0dd76f7fae0df8d2e5ac77efef61eda refs/tags/v0.1.0
6b3353d7da4280f71c0c23fefd5a49390e8d98b7 refs/tags/v0.1.0^{}
c7125bdbffdef67bd8113d5be7a011ad92ba4d80 refs/tags/v0.2.0
0258b92fc637d3c6faeff3d653ad0d67387ac9aa refs/tags/v0.2.0^{}
65c6c55fc11997ed939d964f8aea257d0209ac47 refs/tags/v0.3.0
a4bb47d108bdd6ee509870e096b1687fb8d3ff56 refs/tags/v0.3.0^{}
89fe9eb380397897df145219ea247f9d76d4ccf3 refs/tags/v0.3.1
5b18e2e7db63a725aa9dc8463a67a90293e68507 refs/tags/v0.3.1^{}

After adding the branch:

bf49a0b1c0dd76f7fae0df8d2e5ac77efef61eda refs/tags/v0.1.0
6b3353d7da4280f71c0c23fefd5a49390e8d98b7 refs/tags/v0.1.0^{}
c7125bdbffdef67bd8113d5be7a011ad92ba4d80 refs/tags/v0.2.0
0258b92fc637d3c6faeff3d653ad0d67387ac9aa refs/tags/v0.2.0^{}
65c6c55fc11997ed939d964f8aea257d0209ac47 refs/tags/v0.3.0
a4bb47d108bdd6ee509870e096b1687fb8d3ff56 refs/tags/v0.3.0^{}

89fe9eb380397897df145219ea247f9d76d4ccf3 refs/tags/v0.3.1
5b18e2e7db63a725aa9dc8463a67a90293e68507 refs/tags/v0.3.1^{}
78bdd2742169d2b281bd7cd0455f4301d580c767 refs/tags/v0.3.2

How can I debug this farther?

Thanks,

Alon

 

HTH

Luca.

>  I have multiple examples of regular users who see only a subset of tags, I've provided all the information I could find and also the helper check.access API, which should be helpful for debugging.
>
> I could not find what is wrong in the configuration and what is the difference between the use cases, it seems that the simple tags are more subject to be hidden.
>  Thanks,
> Alon
>
> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/e4bc9ae7-b126-45a0-836a-9612401ce59an%40googlegroups.com.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/B57225C9-C7CD-41F3-887D-79378ED644A1%40gmail.com.

[Sven Selberg]

On Tuesday, January 6, 2026 at 12:10:30 PM UTC+1 Alon Bar-Lev wrote:

On Tue, 6 Jan 2026 at 08:03, Luca Milanesio <luca.mi...@gmail.com> wrote:

> On 6 Jan 2026, at 00:25, 'Kenyon Ralph' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
>
> On Monday, December 29, 2025 at 11:05:03 PM UTC-8 Alon Bar-Lev wrote:
> Hi,
>
> Has anyone encountered an issue in which tags are partially visible to users and succeeded to solve this without allowing refs/*?
>
> I don't have a good answer, but I also have encountered this issue on Gerrit 3.11.1. My solution was to allow Read on refs/*. In my case, I could tell from ls-user-refs that the user could read the branch that contains the commit the tag points to, but still he could not see the tag. I posted about it on the Gerrit Discord on June 5, 2025: https://discord.com/channels/775374026587373568/775374026587373571/1380321249422737571


The visibility of tags is a lot more complex than the visibility on any other refs.
Instead of just maching the ref name, it is also based on reachability by visible branches.

Have you tried creating a branch that points to the SHA1 of the tag and it is visible by the user?
If that shows the tags, then it means that you have a reachability issue.

Hi Luca,

Thank you for the suggestion, after creating a branch out of the tag v0.3.2 with name stable-alon, the user sees the tag.

I do not understand the reachability issue.

To me this smells like a reachability bug for lightweight tags. It could also be an issue with the git_tags cache. or a combination of the two.
(we don't allow lightweight tags on our instance because they tend to lead into corner-cases, and also lacks the traceability of annotated tags)

I would guess that the reason the stable-alon branch make the tag visible is because it references the same commit as the v0.3.2 tag.
You could try to delete stable-alon and create a new branch to a child commit of 78bdd2742169d2b281bd7cd0455f4301d580c767.

My guess is that the tag stops being visible.

If the tag remains visible it could be that the tag is still in the git_tags cache because your stable-alon branch worked around the visibility bug and added it to the cache.

 

Couldn't see anywhere in the thread if READ for "refs/tags/*" solves the visibility issue.
I would try this also.

[Sven Selberg]

On Wednesday, January 7, 2026 at 9:11:49 AM UTC+1 Sven Selberg wrote:

On Tuesday, January 6, 2026 at 12:10:30 PM UTC+1 Alon Bar-Lev wrote:

On Tue, 6 Jan 2026 at 08:03, Luca Milanesio <luca.mi...@gmail.com> wrote:

> On 6 Jan 2026, at 00:25, 'Kenyon Ralph' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
>
> On Monday, December 29, 2025 at 11:05:03 PM UTC-8 Alon Bar-Lev wrote:
> Hi,
>
> Has anyone encountered an issue in which tags are partially visible to users and succeeded to solve this without allowing refs/*?
>
> I don't have a good answer, but I also have encountered this issue on Gerrit 3.11.1. My solution was to allow Read on refs/*. In my case, I could tell from ls-user-refs that the user could read the branch that contains the commit the tag points to, but still he could not see the tag. I posted about it on the Gerrit Discord on June 5, 2025: https://discord.com/channels/775374026587373568/775374026587373571/1380321249422737571


The visibility of tags is a lot more complex than the visibility on any other refs.
Instead of just maching the ref name, it is also based on reachability by visible branches.

Have you tried creating a branch that points to the SHA1 of the tag and it is visible by the user?
If that shows the tags, then it means that you have a reachability issue.

Hi Luca,

Thank you for the suggestion, after creating a branch out of the tag v0.3.2 with name stable-alon, the user sees the tag.

I do not understand the reachability issue.

To me this smells like a reachability bug for lightweight tags. It could also be an issue with the git_tags cache. or a combination of the two.
(we don't allow lightweight tags on our instance because they tend to lead into corner-cases, and also lacks the traceability of annotated tags)

I would guess that the reason the stable-alon branch make the tag visible is because it references the same commit as the v0.3.2 tag.
You could try to delete stable-alon and create a new branch to a child commit of 78bdd2742169d2b281bd7cd0455f4301d580c767.

My guess is that the tag stops being visible.

If the tag remains visible it could be that the tag is still in the git_tags cache because your stable-alon branch worked around the visibility bug and added it to the cache.

I.e. If it remains visible after you moved the stable-alon branch you could try to clear the git_tags cache (perhaps not viable depending on how large your Gerrit instance is or whether you can replicate the situation in a staging environment).

[Nasser Grainawi]

The other thing you could check (in addition to what Sven said) would be to run the above git debug commands on the Gerrit server itself, just on the chance that your local refs don't match what's actually on the server.

 

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/CAOazyz0cXNFHWUjH7d2Jb%2BEhW-PvtrC8%3DTv%3DXFwLQmx6KzuY8A%40mail.gmail.com.

[Alon Bar-Lev]

Thanks, as I am monitoring it from my clone while the user is in another clone I am sure this is not the case.

However, to make sure, I tried this locally from the gerrit server git repo.

Refs are exactly the same.

$ git log --oneline origin/stable-0.3
ee7cca8 (origin/stable-0.3) release: prepare for 0.3.3

78bdd27 (tag: v0.3.2, origin/stable-alonbl-2) bugfix: filtering duplicate

0ef11e9 release: prepare for 0.3.2
5b18e2e (tag: v0.3.1) bugfix: support 
d0e8d8b release: Prepare for 0.3.1
a4bb47d (tag: v0.3.0) bugfix: keep enough

I am waiting for the user to test the  stable-alonbl-2 per Sven request.

[Alon Bar-Lev]

On Wed, 7 Jan 2026 at 10:50, Sven Selberg <sven.s...@axis.com> wrote:

On Wednesday, January 7, 2026 at 9:11:49 AM UTC+1 Sven Selberg wrote:

On Tuesday, January 6, 2026 at 12:10:30 PM UTC+1 Alon Bar-Lev wrote:

On Tue, 6 Jan 2026 at 08:03, Luca Milanesio <luca.mi...@gmail.com> wrote:

> On 6 Jan 2026, at 00:25, 'Kenyon Ralph' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
>
> On Monday, December 29, 2025 at 11:05:03 PM UTC-8 Alon Bar-Lev wrote:
> Hi,
>
> Has anyone encountered an issue in which tags are partially visible to users and succeeded to solve this without allowing refs/*?
>
> I don't have a good answer, but I also have encountered this issue on Gerrit 3.11.1. My solution was to allow Read on refs/*. In my case, I could tell from ls-user-refs that the user could read the branch that contains the commit the tag points to, but still he could not see the tag. I posted about it on the Gerrit Discord on June 5, 2025: https://discord.com/channels/775374026587373568/775374026587373571/1380321249422737571


The visibility of tags is a lot more complex than the visibility on any other refs.
Instead of just maching the ref name, it is also based on reachability by visible branches.

Have you tried creating a branch that points to the SHA1 of the tag and it is visible by the user?
If that shows the tags, then it means that you have a reachability issue.

Hi Luca,

Thank you for the suggestion, after creating a branch out of the tag v0.3.2 with name stable-alon, the user sees the tag.

I do not understand the reachability issue.

To me this smells like a reachability bug for lightweight tags. It could also be an issue with the git_tags cache. or a combination of the two.
(we don't allow lightweight tags on our instance because they tend to lead into corner-cases, and also lacks the traceability of annotated tags)

I would guess that the reason the stable-alon branch make the tag visible is because it references the same commit as the v0.3.2 tag.
You could try to delete stable-alon and create a new branch to a child commit of 78bdd2742169d2b281bd7cd0455f4301d580c767.

My guess is that the tag stops being visible.

If the tag remains visible it could be that the tag is still in the git_tags cache because your stable-alon branch worked around the visibility bug and added it to the cache.

I.e. If it remains visible after you moved the stable-alon branch you could try to clear the git_tags cache (perhaps not viable depending on how large your Gerrit instance is or whether you can replicate the situation in a staging environment).

 

Hi,

I added the branch and the tag was visible.

Then I removed the branch.

And surprise, the tag is still visible....

I am unsure what I can do now to assist resolving the issue we had, as the current state is the same as before.

Thank you for your support,

Alon

 

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/1699b631-9e2c-43b6-adf0-742baff687ban%40googlegroups.com.

[Luca Milanesio]

That looks a caching issue then.

Next time it happens, flush the caches and check if the problem goes away.
If it does goes away, then it is confirmed as caching.

HTH

Luca.

> To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/CAOazyz1rncoXghwmS6vVRUoKz85hmY%3DXCzK%2BhZL8yXxsbMFXuw%40mail.gmail.com.

[Nasser Grainawi]

There's at least one known bug in the tag cache. The simplified DAG rewrite of the tag cache fixes that bug (but introduces a performance issue) so there's a test you can see passing on top of that change that fails without it: 227513: RefAdvertisementIT: add uploadPackBranchFFMakeTagReachableVisible test | https://gerrit-review.googlesource.com/c/gerrit/+/227513

 

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/7EA6261D-9A08-40D1-8735-6A060912F270%40gmail.com.

[Matthias Sohn]

Is the performance issue this change introduces documented somewhere ? 

I couldn't find perf results in the review discussions on that change.

 

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/CAFcKa%3D9S6pxHTxjC_%2BEZB%3DBULPCTj3nEzvHQgA7Kis%3D5NiHaZA%40mail.gmail.com.

[Nasser Grainawi]

Doesn't look like it made it anywhere public. I looked back through
internal chat history and I was discussing with @mfick about potential
slowness building a TagSet. The last note on it was some hunch about
"the slowness problem in refresh() is the dag.prune() walking too many
commits instead of limiting to only the ones that were updated". We
were going to comment out the prune() and re-test, but that was
Martin's last day at Qualcomm, so I don't know if that ever happened.
If you think you could have time to help review/test it, I can try to
find time to rebase and fix the merge conflicts.