Gerrit Config question

[Ray Pelkey]

Hi

I've been trying to sort out the config changes in our gerrit.config file to accommodate this:

https://code.google.com/p/gerrit/issues/detail?id=175

in summary this suggests:
but it's not clear if this is a gerrit config or project config change.  Can't seem to locate any doc to sort this out for either.

Seems on Gerrit server side one would want to set:

uploadpack.hideRefs refs/changes
uploadpack.hideRefs refs/cache-automerge
uploadpack.allowtipsha1inwant = true

 
I've tried a few different things.

like:
[uploadpack]
        hideRefs refs/changes
        hideRefs refs/cache-automerge
        allowtipsha1inwant = true
and..

[upload]
        hideRefs refs/changes
        hideRefs refs/cache-automerge
        allowtipsha1inwant = true

but neither work

Gerrit version is 2.11

can any one point me to the right syntax?

thanks!

[Edwin Kempin]

2015-07-01 20:54 GMT+02:00 Ray Pelkey <ray.p...@here.com>:

Hi

I've been trying to sort out the config changes in our gerrit.config file to accommodate this:

Which exact problem do you want to solve?
 

https://code.google.com/p/gerrit/issues/detail?id=175

in summary this suggests:
but it's not clear if this is a gerrit config or project config change.  Can't seem to locate any doc to sort this out for either.

Seems on Gerrit server side one would want to set:

uploadpack.hideRefs refs/changes
uploadpack.hideRefs refs/cache-automerge
uploadpack.allowtipsha1inwant = true

 
I've tried a few different things.

like:
[uploadpack]
        hideRefs refs/changes
        hideRefs refs/cache-automerge
        allowtipsha1inwant = true
and..

[upload]
        hideRefs refs/changes
        hideRefs refs/cache-automerge
        allowtipsha1inwant = true

I don't think that these options are supported.

In any case the syntax looks incorrect, it should rather be

[uploadpack]
        hideRefs = refs/changes
        hideRefs = refs/cache-automerge
        allowtipsha1inwant = true

 

but neither work

Gerrit version is 2.11

can any one point me to the right syntax?

thanks!

--
--
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/d/optout.

[Christian Aistleitner]

Hi,

just to connect things ... this issue has also been brought up in the
Wikimedia bug tracker some days back:
https://phabricator.wikimedia.org/T103990

(More responses below inline)

On Wed, Jul 01, 2015 at 10:18:23PM +0200, Edwin Kempin wrote:
> 2015-07-01 20:54 GMT+02:00 Ray Pelkey <ray.p...@here.com>:
> > but it's not clear if this is a gerrit config or project config change.

Neither.
This setting belongs in the config file of the git repo.

So for the All-Projects project, that would be

$SITE/git/All-Projects.git/config

for the project "foo" it would be

$SITE/git/foo.git/config

. You get the picture :-)

> In any case the syntax looks incorrect, it should rather be
>
> [uploadpack]
> hideRefs = refs/changes
> hideRefs = refs/cache-automerge
> allowtipsha1inwant = true

While Edwin's syntax is correct, it might not do what you expect it to
do. It would hide only the (non-existing) "refs/changes" (exact
match), but it would happily continue to advertise refs like
"refs/changes/12/512/1".

So judging from the quoted bug of OP, exact matching is not what you
want, but you want prefix matching. To switch to prefix matching, add
a trailing slash ("/") to the refs. So the final config would look
like:

[uploadpack]
hideRefs = refs/changes/
hideRefs = refs/cache-automerge/
allowtipsha1inwant = true

With that config, refs like "refs/changes/12/512/1" no longer get
advertized. \o/

What sounds like a win, isn't a win, because with that config you can
now no longer fetch the ref. So the fetch/pull/... commands that
Gerrit shows on the change screen no longer work. E.g.:

git fetch origin refs/changes/12/512/1

would no longer work. Hence, many tools that ease the gerrit workflow
would break.

What you can use though to fetch commits, is the plain sha1 of the
commit (allowtipsha1inwant :-)). So if the above ref would point at,
say, 28f8a185c732940b3dca7a5773ccd80c9b484afa, then

git fetch origin 28f8a185c732940b3dca7a5773ccd80c9b484afa

would work (if you use a recent enough git client). But for that to
work, obviously one needs to know the commit hash beforehand. :-(
So the uploadpack config is not a solution either from my point of
view.

Have fun,
Christian



--
---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
Companies' registry: 360296y in Linz
Christian Aistleitner
Kefermarkterstrasze 6a/3 Email: chri...@quelltextlich.at
4293 Gutau, Austria Phone: +43 7946 / 20 5 81
Fax: +43 7946 / 20 5 81
Homepage: http://quelltextlich.at/
---------------------------------------------------------------

[Edwin Kempin]

Cool, I didn't know that jgit supports this configuration.

 

What sounds like a win, isn't a win, because with that config you can
now no longer fetch the ref. So the fetch/pull/... commands that
Gerrit shows on the change screen no longer work. E.g.:

  git fetch origin refs/changes/12/512/1

would no longer work. Hence, many tools that ease the gerrit workflow
would break.

What you can use though to fetch commits, is the plain sha1 of the
commit (allowtipsha1inwant :-)). So if the above ref would point at,
say, 28f8a185c732940b3dca7a5773ccd80c9b484afa, then

  git fetch origin 28f8a185c732940b3dca7a5773ccd80c9b484afa

would work (if you use a recent enough git client). But for that to
work, obviously one needs to know the commit hash beforehand. :-(

It should be easy to overcome this by adapting the download commands:
  https://gerrit-review.googlesource.com/69280
 

[Christian Aistleitner]

Hi Edwin,

On Thu, Jul 02, 2015 at 08:26:37AM +0200, Edwin Kempin wrote:
> It should be easy to overcome this by adapting the download commands:
> https://gerrit-review.googlesource.com/69280

Awesome!
That would be cool :-)

[Ray Pelkey]

Thanks for the help Edwin and Christian,

This helped out quite a lot.

[Bassem Rabil]

Hi

I see this change would adapt the download commands to show commit SHA-1 instead of refs, but what about the impact of hiding these references on the replication plugin ?

For those who uses this hiding feature, how do you configure replication plugin to replicate changes to slaves ? 

Thanks

Bassem

[Sebastian Schuberth]

On Wednesday, July 1, 2015 at 11:56:47 PM UTC+2, Christian Aistleitner wrote:

 

> > but it's not clear if this is a gerrit config or project config change.

Neither.
This setting belongs in the config file of the git repo.

So for the All-Projects project, that would be

  $SITE/git/All-Projects.git/config

for the project "foo" it would be

  $SITE/git/foo.git/config

. You get the picture :-)

That for spelling that our clearly. if I'm not mistaken, this implied that

1) this configuration change cannot be made via the Gerrit UI.

2) You how to turn this on for each and every repository individually. Turning it on for "$SITE/git/All-Projects.git/config" will not automatically turn it on for projects that inherit (in the Gerrit sense) from All-Projects.

Are both these statements correct?

Regards,
Sebastian

[chri...@quelltextlich.at]

Hi Sebastian,

On Fri, Apr 21, 2017 at 02:16:55AM -0700, Sebastian Schuberth wrote:
> On Wednesday, July 1, 2015 at 11:56:47 PM UTC+2, Christian Aistleitner
> wrote:

> > [uploadpack config in repo]

>
> That for spelling that our clearly. if I'm not mistaken, this implied that
>
> 1) this configuration change cannot be made via the Gerrit UI.
>
> 2) You how to turn this on for each and every repository individually.
> Turning it on for "$SITE/git/All-Projects.git/config" will not
> automatically turn it on for projects that inherit (in the Gerrit sense)
> from All-Projects.
>
> Are both these statements correct?

Unfortunately, I think they are correct.

However, turning it on for each and every repo should not be too hard
and only be a question of a small shell script.

[Sebastian Schuberth]

On Fri, Apr 21, 2017 at 12:40 PM, <chri...@quelltextlich.at> wrote:

>> 1) this configuration change cannot be made via the Gerrit UI.
>>
>> 2) You how to turn this on for each and every repository individually.
>> Turning it on for "$SITE/git/All-Projects.git/config" will not
>> automatically turn it on for projects that inherit (in the Gerrit sense)
>> from All-Projects.
>>
>> Are both these statements correct?
>
> Unfortunately, I think they are correct.
>
> However, turning it on for each and every repo should not be too hard
> and only be a question of a small shell script.

You're right that technically this is not very challenging, but
process-wise it's a bit annoying if you yourself are not the Gerrit
admin.

--
Sebastian Schuberth