Search
Clear search
Close search
Main menu
Google apps

direct url fails on 3.10 result in error 404

235 views
Skip to first unread message

Peter Bruin

unread,
Sep 2, 2024, 6:59:50 AM9/2/24
to Repo and Gerrit Discussion
After upgrading to 3.10 from 3.6.8 we can't access the url directly anymore.
Example: http://server/r/project/123 fails when copy/paste but works when it is redirected from the dash board. Also, using F5 to refresh will also result in error 404

We are using gerrit behind an apache reverse proxy. Do we maybe need to set some cookie? Seems like some authentication issue.

Although this is not a major issue it is a but annoying as this breaks the link from Jenkins jobs to gerrit.

Thanks,
Peter Bruin

Luca Milanesio

unread,
Sep 2, 2024, 8:19:21 AM9/2/24
to Repo and Gerrit Discussion, Luca Milanesio

On 2 Sep 2024, at 07:59, Peter Bruin <peterb...@gmail.com> wrote:

After upgrading to 3.10 from 3.6.8 we can't access the url directly anymore.
Example: http://server/r/project/123 fails when copy/paste but works when it is redirected from the dash board. Also, using F5 to refresh will also result in error 404

I tried on 3.10.1 and http://server/r/project/123 is redirected to http://server/q/project/123 and does not return anything
I also tried on 3.6.8 and I get the same behaviour.

Please note that http://server/r/project/123 doesn’t look like the correct way to identity change 123 on project.

The correct URL is: http://server/c/project/+/123

We are using gerrit behind an apache reverse proxy.

I believe there must be some “magic rules” on your reverse proxy to make your URL work.

Do we maybe need to set some cookie? Seems like some authentication issue.

Although this is not a major issue it is a but annoying as this breaks the link from Jenkins jobs to gerrit.

You should be able to solve it by adjusting your reverse proxy.

HTH

Luca.


Thanks,
Peter Bruin

--
--
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 on the web visit https://groups.google.com/d/msgid/repo-discuss/08f58481-0903-412c-863b-5bbe1e638d3en%40googlegroups.com.

Peter Bruin

unread,
Sep 2, 2024, 12:19:58 PM9/2/24
to Repo and Gerrit Discussion
Hi Luca,
Thanks for your quick reply.

Yes you are right.
Sorry for my mistake
The url is indeed like this:


The apache config:
  ProxyRequests Off
  ProxyVia Off
  ProxyPreserveHost On

  # Gerrit reverse proxy configuration
  AllowEncodedSlashes On
  ProxyPass /r/ http://gerrit3:8081/r/ nocanon

gerrit.conf:

[gerrit]
        basePath = git
        canonicalWebUrl = https:// server.domain.net/r/
[httpd]
        listenUrl = proxy-https://*:8081/r/


I have been looking into it a bit more and noticed that some of the other projects are working. The main project, with 99% of all commits, has a lot a access rules. Could there be an issue there.
Basically I can see all the changes, just when I refresh the page I get the error 404..
I don't see any errors in neither the apache logs or the gerrit logs.

Thanks,
Peter

Luca Milanesio

unread,
Sep 2, 2024, 1:42:47 PM9/2/24
to Repo and Gerrit Discussion, Luca Milanesio

On 2 Sep 2024, at 13:19, Peter Bruin <peterb...@gmail.com> wrote:

Hi Luca,
Thanks for your quick reply.

Yes you are right.
Sorry for my mistake
The url is indeed like this:


The apache config:
  ProxyRequests Off
  ProxyVia Off
  ProxyPreserveHost On

  # Gerrit reverse proxy configuration
  AllowEncodedSlashes On
  ProxyPass /r/ http://gerrit3:8081/r/ nocanon

gerrit.conf:

[gerrit]
        basePath = git
        canonicalWebUrl = https:// server.domain.net/r/
[httpd]
        listenUrl = proxy-https://*:8081/r/


I have been looking into it a bit more and noticed that some of the other projects are working. The main project, with 99% of all commits, has a lot a access rules. Could there be an issue there.
Basically I can see all the changes, just when I refresh the page I get the error 404..

What’s the URL you see in Gerrit’s HTTP log that serves the 404?
Does it work if you bypass the reverse proxy?

I don't see any errors in neither the apache logs or the gerrit logs.

That’s not possible: if you see a 404, either Apache or Gerrit is serving it and you must see the entry in the logs.

If you don’t, then it is possible that the request is blocked before even reaching Apache.
(Content filtering? Security firewall? Security software on your laptop?)

HTH

Luca.

Peter Bruin

unread,
Sep 2, 2024, 2:09:48 PM9/2/24
to Repo and Gerrit Discussion

Found the one line in the apache log:
172.25.11.231 - - [02/Sep/2024:21:50:25 +0800] "GET /r/c/group/project/+/11280 HTTP/1.1" 404 9
[02/Sep/2024:21:50:25 +0800] 172.25.11.231 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /r/c/group/project/+/11280 HTTP/1.1" 9

In the gerrit error_log:
[2024-09-02T21:57:57.561+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Starting timer for Loading accounts (Metadata{pluginMetadata=[], resourceCount=1})
[2024-09-02T21:57:57.562+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Loading accounts (Metadata{pluginMetadata=[], resourceCount=1}) done (0 ms)
[2024-09-02T21:57:57.562+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Starting timer for Loading accounts (Metadata{pluginMetadata=[], resourceCount=1})
[2024-09-02T21:57:57.562+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Loading accounts (Metadata{pluginMetadata=[], resourceCount=1}) done (0 ms)
[2024-09-02T21:58:45.344+08:00] [PluginScanner] DEBUG com.google.gerrit.server.plugins.UniversalServerPluginProvider : File /var/gerrit/plugins/avatars-gravatar.jar handled by gerrit ? => true [CONTEXT PLUGIN="gerrit" ]

Basically, it works when I click on the link in the dash board but not if I right click and select "Open in new tab"

This is what a successful call looks like in the apache logs:
[02/Sep/2024:22:00:25 +0800] 172.25.11.231 TLSv1.3 TLS_AES_256_GCM_SHA384 "-" -
172.25.11.231 - - [02/Sep/2024:22:00:25 +0800] "GET /r/auth-check HTTP/1.1" 204 -
[02/Sep/2024:22:00:25 +0800] 172.25.11.231 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /r/auth-check HTTP/1.1" -
172.25.11.231 - - [02/Sep/2024:22:00:25 +0800] "GET /r/changes/group%2Fproject~11280/revisions/current/ported_comments/ HTTP/1.1" 200 8
[02/Sep/2024:22:00:25 +0800] 172.25.11.231 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /r/changes/group%2Fproject~11280/revisions/current/ported_comments/ HTTP/1.1" 8
172.25.11.231 - - [02/Sep/2024:22:00:25 +0800] "GET /r/changes/group%2Fproject~11280/comments?enable-context=true&context-padding=3 HTTP/1.1" 200 8
[02/Sep/2024:22:00:25 +0800] 172.25.11.231 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /r/changes/group%2Fproject~11280/comments?enable-context=true&context-padding=3 HTTP/1.1" 8
172.25.11.231 - - [02/Sep/2024:22:00:25 +0800] "GET /r/changes/group%2Fproject~11280/robotcomments HTTP/1.1" 200 8
[02/Sep/2024:22:00:25 +0800] 172.25.11.231 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /r/changes/group%2Fproject~11280/robotcomments HTTP/1.1" 8
172.25.11.231 - - [02/Sep/2024:22:00:25 +0800] "GET /r/changes/group%2Fproject~11280/revisions/current/ported_drafts/ HTTP/1.1" 200 8
[02/Sep/2024:22:00:25 +0800] 172.25.11.231 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /r/changes/group%2Fproject~11280/revisions/current/ported_drafts/ HTTP/1.1" 8

Please let me know if you would like more log info.

Luca Milanesio

unread,
Sep 2, 2024, 9:13:57 PM9/2/24
to Repo and Gerrit Discussion, Luca Milanesio

On 2 Sep 2024, at 15:09, Peter Bruin <peterb...@gmail.com> wrote:


Found the one line in the apache log:
172.25.11.231 - - [02/Sep/2024:21:50:25 +0800] "GET /r/c/group/project/+/11280 HTTP/1.1" 404 9
[02/Sep/2024:21:50:25 +0800] 172.25.11.231 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /r/c/group/project/+/11280 HTTP/1.1" 9

In the gerrit error_log:
[2024-09-02T21:57:57.561+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Starting timer for Loading accounts (Metadata{pluginMetadata=[], resourceCount=1})
[2024-09-02T21:57:57.562+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Loading accounts (Metadata{pluginMetadata=[], resourceCount=1}) done (0 ms)
[2024-09-02T21:57:57.562+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Starting timer for Loading accounts (Metadata{pluginMetadata=[], resourceCount=1})
[2024-09-02T21:57:57.562+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Loading accounts (Metadata{pluginMetadata=[], resourceCount=1}) done (0 ms)
[2024-09-02T21:58:45.344+08:00] [PluginScanner] DEBUG com.google.gerrit.server.plugins.UniversalServerPluginProvider : File /var/gerrit/plugins/avatars-gravatar.jar handled by gerrit ? => true [CONTEXT PLUGIN="gerrit" ]

You should look at the Gerrit’s httpd_log and see if you can find the call:
GET /c/group/project/+/11280

(It should be without the ‘/r’)

Also, is the project / change public or does it require authentication?
Is the call reaching Gerrit authenticated or not?

Peter Bruin

unread,
Sep 3, 2024, 12:31:40 AM9/3/24
to Repo and Gerrit Discussion
172.25.54.144 [HTTP-127] - BRUIN_ADMIN [2024-09-03T08:28:31.558+08:00] "GET /r/c/group/project/+/11280 HTTP/1.1" 404 9 3 - "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36" 2 - 96376 -
I have tried both my normal account and my admin account, as I am a global admin, there should not be any restrictions.

Luca Milanesio

unread,
Sep 3, 2024, 10:06:33 PM9/3/24
to Repo and Gerrit Discussion, Luca Milanesio
On 3 Sep 2024, at 01:31, Peter Bruin <peterb...@gmail.com> wrote:

172.25.54.144 [HTTP-127] - BRUIN_ADMIN [2024-09-03T08:28:31.558+08:00] "GET /r/c/group/project/+/11280 HTTP/1.1" 404 9 3 - "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36" 2 - 96376 -
I have tried both my normal account and my admin account, as I am a global admin, there should not be any restrictions.

Please avoid top posting on this list, use interleaved posting instead.

If you search for “top posting” on the repo-discuss mailing list, you’ll notice that this has been said and reminded up to 100 times (or more).

I’ve created also a change (see [1]) where we explicitly mention our policy.


On Tuesday 3 September 2024 at 05:13:57 UTC+8 Luca Milanesio wrote:

On 2 Sep 2024, at 15:09, Peter Bruin <peterb...@gmail.com> wrote:


Found the one line in the apache log:
172.25.11.231 - - [02/Sep/2024:21:50:25 +0800] "GET /r/c/group/project/+/11280 HTTP/1.1" 404 9
[02/Sep/2024:21:50:25 +0800] 172.25.11.231 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /r/c/group/project/+/11280 HTTP/1.1" 9

In the gerrit error_log:
[2024-09-02T21:57:57.561+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Starting timer for Loading accounts (Metadata{pluginMetadata=[], resourceCount=1})
[2024-09-02T21:57:57.562+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Loading accounts (Metadata{pluginMetadata=[], resourceCount=1}) done (0 ms)
[2024-09-02T21:57:57.562+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Starting timer for Loading accounts (Metadata{pluginMetadata=[], resourceCount=1})
[2024-09-02T21:57:57.562+08:00] [HTTP-903] DEBUG com.google.gerrit.server.logging.TraceContext.TraceTimer : Loading accounts (Metadata{pluginMetadata=[], resourceCount=1}) done (0 ms)
[2024-09-02T21:58:45.344+08:00] [PluginScanner] DEBUG com.google.gerrit.server.plugins.UniversalServerPluginProvider : File /var/gerrit/plugins/avatars-gravatar.jar handled by gerrit ? => true [CONTEXT PLUGIN="gerrit" ]

You should look at the Gerrit’s httpd_log and see if you can find the call:
GET /c/group/project/+/11280

(It should be without the ‘/r’)

172.25.54.144 [HTTP-127] - BRUIN_ADMIN [2024-09-03T08:28:31.558+08:00] "GET /r/c/group/project/+/11280 HTTP/1.1" 404 9 3 - "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36" 2 - 96376 -


See your URL in the above log line: can you notice the extra ‘/r/‘ ?
The problem is in your reverse proxy that doesn’t remove it.

The path /r/c/group/project/+/11280 is invalid because of the extra ‘/r/‘.


Also, is the project / change public or does it require authentication?
Is the call reaching Gerrit authenticated or not?

The ACLs are fine, Gerrit is fine, your reverse proxy rule has issues, because the incoming call /r/c/group/project/+/11280 should have been proxied to /c/group/project/+/11280 (without the ‘/r/‘).

See some sample reverse proxy rules at [2].

HTH


Peter Bruin

unread,
Sep 5, 2024, 11:17:15 AM9/5/24
to Repo and Gerrit Discussion
On 5 Sep 2024, at 11:03, Peter Bruin <peterb...@gmail.com> wrote:



The problem is not related to the reverse proxy configuration as it occurs on a group of projects and not on  another group.

 /r/c/group1/project1/+/11280 fails
 /r/c/group2/project2/+/11281 passes

Anyway, I have created a copy of the gerrit site and removed the reverse proxy to make sure that is not the issue and the problem was still there.
Next I retrieved the site before the upgrade with 3.5.1 from the backups and went through the upgrade process again without skipping any minors.
Conclusion is that 3.9.6 causes the issue and downgrading to 3.9.5 makes it go away.

So the issue is navigating from the dashboard to the change, which works, and then using refresh which fails to error 404.

This was all tested with only gerrit running.
The adjusted gerrit.config

[gerrit]
       basePath = git
       canonicalWebUrl = http://gerrit2.domain.net:8081/r/
[httpd]
       listenUrl = proxy-http://*:8081/r/

For the url, I have tried both with and without trailing '/' but this didn't make a difference

As we upgraded on our production site from 3.6.8 to 3.10.1, I am wondering if we can still downgrade to 3.9.5 to get rid of this issue.

BTW, hope this posting is better... sorry for the top posts.. 


The path /r/c/group/project/+/11280 is invalid because of the extra ‘/r/‘.


Also, is the project / change public or does it require authentication?
Is the call reaching Gerrit authenticated or not?

The ACLs are fine, Gerrit is fine, your reverse proxy rule has issues, because the incoming call /r/c/group/project/+/11280 should have been proxied to /c/group/project/+/11280 (without the ‘/r/‘).

See some sample reverse proxy rules at [2].

HTH

Luca Milanesio

unread,
Sep 5, 2024, 11:20:18 AM9/5/24
to Repo and Gerrit Discussion, Luca Milanesio
That’s curious, because I tried with Gerrit v3.10:

a) Create a project ‘foo’
b) Create a change 1
c) Access the change with /c/foo/+1 => works
d) Access the change with /r/c/foo/+1 => fails

The failure *is expected IMHO*, because the ‘/r/‘ is invalid.

Let me try with v3.9.5.

Peter Bruin

unread,
Sep 5, 2024, 11:31:32 AM9/5/24
to Repo and Gerrit Discussion
I have removed the /r from the url and the behavior is still the same.
I was suspecting the access right and moved the inheritance from project1 on group 1 to inherit the access rights from group2 and this does not fix the issue.
 


Anyway, I have created a copy of the gerrit site and removed the reverse proxy to make sure that is not the issue and the problem was still there.
Next I retrieved the site before the upgrade with 3.5.1 from the backups and went through the upgrade process again without skipping any minors.
Conclusion is that 3.9.6 causes the issue and downgrading to 3.9.5 makes it go away.

So the issue is navigating from the dashboard to the change, which works, and then using refresh which fails to error 404.

This was all tested with only gerrit running.
The adjusted gerrit.config

[gerrit]
       basePath = git
       canonicalWebUrl = http://gerrit2.domain.net:8081/r/
[httpd]
       listenUrl = proxy-http://*:8081/r/

For the url, I have tried both with and without trailing '/' but this didn't make a difference

As we upgraded on our production site from 3.6.8 to 3.10.1, I am wondering if we can still downgrade to 3.9.5 to get rid of this issue.

BTW, hope this posting is better... sorry for the top posts.. 


The path /r/c/group/project/+/11280 is invalid because of the extra ‘/r/‘.


Also, is the project / change public or does it require authentication?
Is the call reaching Gerrit authenticated or not?

The ACLs are fine, Gerrit is fine, your reverse proxy rule has issues, because the incoming call /r/c/group/project/+/11280 should have been proxied to /c/group/project/+/11280 (without the ‘/r/‘).

See some sample reverse proxy rules at [2].

HTH

Luca Milanesio

unread,
Sep 5, 2024, 11:57:58 AM9/5/24
to Repo and Gerrit Discussion, Luca Milanesio
Done: if you have the ‘/r/‘ in the prefix you get a 404 (expected) in v3.9.5. When you remove the ‘/r/‘ it works (expected).
>
> I have removed the /r from the url and the behavior is still the same.

I believe you have anyway a bug in your gerrit.config:

> [gerrit]
> basePath = git
> canonicalWebUrl = http://gerrit2.domain.net:8081/r/
The above should be http://gerrit2.domain.net:8081/

> [httpd]
> listenUrl = proxy-http://*:8081/r/
The above should be http://*:8081


> I was suspecting the access right and moved the inheritance from project1 on group 1 to inherit the access rights from group2 and this does not fix the issue.

You should try to reproduce it with Gerrit in isolation first, using a test environment.

HTH

Luca.
> To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/62481431-8418-4ff4-8b7f-8637e214d2c4n%40googlegroups.com.

Luca Milanesio

unread,
Sep 5, 2024, 12:29:31 PM9/5/24
to Repo and Gerrit Discussion, Luca Milanesio
I’ve checked the commits between 3.9.5 and 3.9.6 and this one is the only one relevant:
https://gerrit.googlesource.com/gerrit/+/2e6314d195a489a882b2f80fd2f6f9e274482cf1%5E%21/#F0

However, as you can see, it impacts the ‘/c/‘ prefix and not the ‘/r/‘.

serveRegex("^/settings/?$").with(screen(PageLinks.SETTINGS));
serveRegex("^/register$").with(registerScreen(false));
serveRegex("^/register/(.+)$").with(registerScreen(true));
- serveRegex("^(?:/c)?/([1-9][0-9]*)/?$").with(NumericChangeIdRedirectServlet.class);
- serveRegex("^(?:/c)?/([1-9][0-9]*)/comment/\\w+/?$").with(NumericChangeIdRedirectServlet.class);
+ serveRegex("^(?:/c)?/([1-9][0-9]*)/?.*$").with(NumericChangeIdRedirectServlet.class);
serveRegex("^/p/(.*)$").with(queryProjectNew());
serveRegex("^/r/(.+)/?$").with(DirectChangeByCommit.class);

P.S. the ‘/r/‘ prefix is for changes lookup by *commit SHA1* and not by project/change number.

HTTP GET /r/666a6e3ba93f45de9be9eea7c777f072130e9b9b => gets redirected to /c/foo/+/1/

I still suspect you have a misconfiguration because the ‘/r/‘ should have not reached the backend.

Try to put the reverse proxy out of the equation, fixing the gerrit.config as suggested, and see if that works.
If it works, then fix the reverse proxy settings.

Peter Bruin

unread,
Sep 5, 2024, 2:22:16 PM9/5/24
to Repo and Gerrit Discussion
Could the problem be that my group name is: 1AEE1 and that his matches this?
As I mentioned in the previous reply, I have been testing all day without a reverse proxy, purely using gerrit.

Could it be that we followed the recommendations to the proxy setup from https://gerrit-documentation.storage.googleapis.com/Documentation/2.9/config-reverseproxy.html ?
I know, it is an old gerrit installation and some funny thing come up every now and then.

I used the regex tester, and indeed /c/1abc1/test/+/223 matches but /c/abc1/test/+/223 does not match the regex.

So it is not the reverse proxy but the parent project name that start with a number that is the problem.
Is this a bug?

Luca Milanesio

unread,
Sep 5, 2024, 2:26:54 PM9/5/24
to Repo and Gerrit Discussion, Luca Milanesio
My 2c:
- reproduce the issue with a plain vanilla Gerrit
- raise the issue on https://issues.gerritcodereview.com with the exact steps to reproduce it

The above would allow us (Gerrit community of contributors) to understand what could be broken

I tried to reproduce the issue but I couldn’t, but if you put clear simple instructions, I will try again :-)

HTH

Luca.
> To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/f3d85f7f-899e-4a81-b76e-a58ad499ba18n%40googlegroups.com.

Peter Bruin

unread,
Sep 5, 2024, 2:30:32 PM9/5/24
to Repo and Gerrit Discussion
You can reproduce this on gerrithub: https://gerrithub.io/c/118DBK/GerritTest/+/484166

Peter Bruin

unread,
Sep 5, 2024, 2:34:34 PM9/5/24
to Repo and Gerrit Discussion
I guess there is already a bug report: https://issues.gerritcodereview.com/issues/360705824

Luca Milanesio

unread,
Sep 7, 2024, 9:56:09 PM9/7/24
to Repo and Gerrit Discussion, Luca Milanesio

On 5 Sep 2024, at 15:30, Peter Bruin <peterb...@gmail.com> wrote:

You can reproduce this on gerrithub: https://gerrithub.io/c/118DBK/GerritTest/+/484166

That is useful, thanks for doing that.
Also, I believe Paradox has already proposed a fix with [2], reviewing it right now.

Thanks again for reporting it and taking the time to reproduce it.

Luca.


Luca Milanesio

unread,
Sep 7, 2024, 11:52:20 PM9/7/24
to Repo and Gerrit Discussion, Luca Milanesio

On 7 Sep 2024, at 22:55, Luca Milanesio <luca.mi...@gmail.com> wrote:



On 5 Sep 2024, at 15:30, Peter Bruin <peterb...@gmail.com> wrote:

You can reproduce this on gerrithub: https://gerrithub.io/c/118DBK/GerritTest/+/484166

That is useful, thanks for doing that.
Also, I believe Paradox has already proposed a fix with [2], reviewing it right now.

Paladox’s fix was incomplete … but I am trying a different approach with [3] where I do redirect ONLY the well-known patterns that should be recognised as change numbers and nothing else.
Hope that would fix it once and for all :-)

Luca.

Peter Bruin

unread,
Sep 10, 2024, 5:50:35 AM9/10/24
to Repo and Gerrit Discussion
Thanks Luca, really appreciate your help on this.
Looking forward to the next release.
Peter

Reply all
Reply to author
Forward
0 new messages