Tags not visible

[Reinhard Nägele]

Hi,

We have a weird problem with tag visibility. We migrated one of our projects from SVN to Gerrit. We have a script that polishes the cloned SVN repo and creates proper annotated tags from SVN tags in the Git repo. One of the project members did the migration himself, pushed the final repo to Gerrit and then cloned it to a new directory from Gerrit. The result was that the user could not see the tags anymore he had previously pushed. When I cloned the repo, I did get all the tags.

Here's the user's rights on refs/tags/*: read, push +force, pushTag, forgeCommitter, forgeAuthor, create.

Myself being an administrator, I additionally have owner rights in the project and read rights on refs/*. I experimented a little bit and found out the following:

• If I create an annotated tag from the current master and push it, the other user can see it:
  git tag -a mytag
• If I create an annotated tag referencing a specific commit and push it, he cannot see it.
  git tag -a mytag <sha1>

What's the difference here? Doesn't read on refs/tags/* suffice to read any tags?

Thanks,
Reinhard

[Magnus Bäck]

On Tuesday, November 19, 2013 at 08:38 EST,

Reinhard Nägele <reinhard...@mgm-tp.com> wrote:

> We have a weird problem with tag visibility. We migrated one of our
> projects from SVN to Gerrit. We have a script that polishes the cloned
> SVN repo and creates proper annotated tags from SVN tags in the Git
> repo. One of the project members did the migration himself, pushed the
> final repo to Gerrit and then cloned it to a new directory from
> Gerrit. The result was that the user could not see the tags anymore he
> had previously pushed. When I cloned the repo, I did get all the tags.

To see a tag, you must have read access to a branch that can reach the
commit it points to.

> Here's the user's rights on refs/tags/*: read, push +force, pushTag,
> forgeCommitter, forgeAuthor, create.
>
> Myself being an administrator, I additionally have owner rights in
> the project and read rights on refs/*. I experimented a little bit
> and found out the following:
>

> - If I create an annotated tag from the current master and push it,

> the other user can see it:
> git tag -a mytag

> - If I create an annotated tag referencing a specific commit and

> push it, he cannot see it.
> git tag -a mytag <sha1>
>
> What's the difference here? Doesn't read on refs/tags/* suffice to
> read any tags?

Nope. Does the user have read access to refs/heads/master but not the
branch(es) that can reach the second tag?

--
Magnus Bäck
ba...@google.com

[Reinhard Nägele]

Thanks for the quick reply. The user does have read access to refs/heads/*. So it looks like the problem lies in the migration from SVN. Only the tags seem to have been migrated but not the branches they were created from.

I find this "feature" somewhat strange when read access on "refs/tags/*" does not mean what it implies. Is this documented anywhere? What's the reasoning behind it?

Reinhard

[Shawn Pearce]

On Tue, Nov 19, 2013 at 7:08 AM, Reinhard Nägele
<reinhard...@mgm-tp.com> wrote:
> Thanks for the quick reply. The user does have read access to refs/heads/*.
> So it looks like the problem lies in the migration from SVN. Only the tags
> seem to have been migrated but not the branches they were created from.

SVN tags are interesting animals to convert to Git. It is somewhat
common in an SVN repository to modify the tag's directory after it has
been copied from the trunk. When this converts to Git the modification
has no corresponding commit on the trunk branch, its unique to the
tag, so the tag becomes this "orphaned" line of development with a
commit or two (or five) that are unique to that tagged version and are
not contained in any other tag or branch.

This isn't the typical use case in Git. Tags are considered
"immutable" and work should be done on a branch, not in a tag. Even
minor fixes required to get a tag to build or embed the correct
version number into the release artifacts should be done on a branch,
and the result of that tagged, and the whole history merged into the
master branch.

> I find this "feature" somewhat strange when read access on "refs/tags/*"
> does not mean what it implies. Is this documented anywhere? What's the
> reasoning behind it?

Gerrit automatically manages the read visibility of a tag based on the
branch history. This was to make it simple for project owners to
manage ACLs. When a tag is created the tag can be pushed to the
repository. If a user can see the point in time the tag references,
the tag is immediately made visible to them. Other tags may be hidden,
e.g. nightly snapshots on an experimental branch that the user does
not have read permission on.

Unfortunately yes, VisibleRefFilter does not honor the read access on
refs/tags/*, or any other prefix starting with refs/tags/. It always
defers to the branches and checks if the tag is accessible from a
branch.

> --
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.