New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 5316 link

Starred by 14 users

Issue metadata

Status: Released
Closed: Nov 14
ReleasedIn: 522.0

Sign in to add a comment

Gitiles links do not work because they use wrong relative paths

Reported by, Jan 22 2017

Issue description

Affected Version:

- Gerrit 640381f50ddfe5c2c73e36d4fafae731678f0202 with Ic2df0f270c178e7a93dde5d0460dd24f10edf321 and I8b674550e34b0c6fed4cc0af2f069aaeadbae6cc applied

- Gitiles 7239ac50bfe6ceda5fa82a37b57ed9b7a6aa7139

When I'm on , there's a "Links" field with a "browse" text which points to gitiles, but the produced URL is . That doesn't work, the "/c/5" should not be there.

In addition, the patchset view shows a short hash of the commit which was merged, but it is not clickable. That thing is clickable on
Status: AwaitingInformation (was: New)
When I go to the "browse" link is:

> the patchset view shows a short hash of the commit which was merged, but it is not clickable

Can you elaborate where this is?  A screenshot would help.
Status: New (was: AwaitingInformation)
Sorry, disregard my previous comments.  I missed that this was for Polygerrit, and I was testing the GWT version...

Comment 3 by, Jan 23 2017

The attached picture shows what gets turned into a link on googlesource, but not on my instance of Polygerrit.
48.8 KB View Download
Project Member

Comment 4 by, Jan 23 2017

Status: Accepted (was: New)
I'm running into this with 2.14-rc0. The "browse" anchor's source is "plugins/gitiles/ansible-repo/+/27e78b687c8dc17e01fe35c4cdd1e153ea942b23" which, when clicked, opens "/c/5/plugins/gitiles/ansible-repo/+/27e78b687c8dc17e01fe35c4cdd1e153ea942b23" which is not correct.
Any update on this? I would assume it's a small change but is extremely frustrating to not have the browse link work.
Project Member

Comment 7 by, Jun 21 2017

Status: AwaitingInformation (was: Accepted)
Is the browse link setup using a weblinks section of that server's Gerrit config file? If so, is it possible that the URL pattern in the "browse" link config needs a slash prepended to it?

Comment 8 by, Aug 1 2017

I believe there is a fix for this issue that needs review at

Comment 9 by, Sep 23 2017

It seems that there are two issues that are getting mixed in this report. The first one of them is that the Gitiles plugin currently only produces relative URLs which do not work. That's being addressed by .

There is also other problem which is illustrated by Comment 3. On a Polygerrit change screen, the commit SHA in between the patchset selection and the Download link is not clickable. Given that it *is* clickable on, it is probably due to some misconfiguration on my side. I'm running with no config for the gitiles plugin, and my server's error log says that the plugin is using its defaults. The documentation says that noWebLinks defaults to false.

> Is the browse link setup using a weblinks section of that server's Gerrit config file? If so, is it possible that the URL pattern in the "browse" link config needs a slash prepended to it?

I am a bit lost here -- the documentation does not contain anything about "weblinks" as far as I can tell. Do I have to enable something to get a clickable link here? This is not about a "commentlink", is it? I also do not have any configuration related to "gitweb" in case that might matter.
Project Member

Comment 10 by, Apr 20 2018

Is this still not working?
Project Member

Comment 11 by, Jun 4

Yes this is still an issue, also on master.

I wanted to point out that the 'browse' link on the file pages are OK, but just wrong on the change page.

So, with Gerrit running under the webroot /, the link generated on a change page for project 'mycategory/myrepo' (e.g. /c/mycategory/myrepo/+/1234) is (wrongfully):


That makes 'c/mycategory//' superfluous in this URL (and yes this is somehow 'missing' the 'myrepo' part).

When viewing the file diff on a page, the link to the file in Gitiles is generated OK:


Versions used:
gerrit 2.15.2-3879-g436b57ea85 from gerrit-ci
gitiles fd51b3f2b9 from gerrit-ci as well
Project Member

Comment 12 by, Jun 6

If you configure an absolute URL for gitweb.url (see, does that resolve this problem?
Project Member

Comment 13 by, Jun 6

 Issue 8656  has been merged into this issue.
Project Member

Comment 14 by, Jun 6

I should note that I haven't installed gitweb in my installation. Are you intentionally pointing to a *gitweb* and not *gitiles* setting - and don't you mean the gitiles.config gerrit.baseUrl setting [1] instead?

With gerrit.config gitweb.url set, nothing changes for Gitiles in my installation. (Same versions used as previous comment.)

I've tried adjusting the gitiles.config gerrit.baseUrl setting and restarted Gerrit, but this only has effect on the change page 'browse' URL generated, *not* on those when viewing a file. Sounds like a(n) (un)related bug?

However, I tried to outsmart the current behaviour here to make it working for my situation by setting the base path to the default but absolute /plugins/gitiles path:

    baseUrl = https://gerrit.mydomain.tld/plugins/gitiles

And now my browse links work everywhere, but this is clearly not how it should be and I still consider this a bug.

Hope this helps.

Project Member

Comment 15 by, Jun 6

Labels: Triaged-Yes Hotlist-Linkification Hotlist-GWT Priority-2
Status: Accepted (was: AwaitingInformation)
My thoughts went to gitweb config because some source browsing plugins use it, but I see now that gitiles has its own config. In any case, I'm glad you found/confirmed a workaround.

What we could do to fix this on PolyGerrit's end is detect when we're given a relative URL for any gitweb or gitiles link, and do the right thing with it to produce an absolute URL. Unfortunately I think this logic is scattered across a number of different components, dealing with a number of different kinds of links.
I have the same issue in Gerrit 2.15.2 but using GitBlit instead of Gitiles. The Links field in the change points to:


Instead of:


I have gitweb.url = https://SERVER/plugins/gitblit/ set in the GERRIT_SITE/etc/gerrit.config file.
The workaround to explicitly set the url worked for me.
I also had to flush the cahces. Ie: ssh -p <port> <host> gerrit flush-caches --all, Are you saying that you set the absolute url, flush the caches and the links field in the change, using PolyGerrit, doesn't add "c/REPO/+" in the link anymore? Is it GitBlit or Gitiles? Which is the Gerrit version? yes that is correct, I added url = http://xyz/gitweb to the [gitweb] section in the configuration and flushed the cache. The flush was necessary since the old page with the incorrect /c/ url was cached after I changed the configuration.
I'm using gitweb on gerrit 2.15.2.
Sorry everyone, I think it was my browser cache :-( The workaround (set the absolute URL using gitweb.url = https://SERVER/plugins/gitblit/ at GERRIT_SITE/etc/gerrit.config file worked pretty well in every "GitBlit" links.
Project Member

Comment 21 by, Jun 28

One issue is that PolyGerrit does not trust the WebLink provider to provide a correct relative URL and tries to second-guess how the WebLink url should be presented.
Project Member

Comment 22 by, Jul 3

ReleasedIn: 522.0
Project Member

Comment 23 by, Jul 9

Status: Released (was: Accepted)
Labels: FixedIn-2.15.3
Project Member

Comment 25 by, Jul 19

Is this really fixed? It's appears not for me at least. I just tested it on master and the behavior is the same as before.

* Verified that is included in master now.
* Upgraded to master/2.15.3-4415-ga24fb63 from gerrit-ci.
* Using gitiles plugin version be8c047 from gerrit-ci.
* Undone my workaround in gitiles.config / gerrit.baseUrl setting.

Generates wrong URLs on 'browse' links, exactly the same as I mentioned in comment 11.

Restoring the workaround in gitiles.config with the new versions generates the right URLs again.
Project Member

Comment 26 by, Jul 20

Labels: -Triaged-Yes Triaged-No
Status: New (was: Released)
Repoening as per report.
Project Member

Comment 27 by, Aug 3

Labels: -Triaged-No Triaged-Undecided
Project Member

Comment 28 by, Aug 19

Components: plugins>gitiles
Labels: FixedIn-2.14.12
Labels: -Triaged-Undecided Triaged-Yes
Labels: Type-Bug
Owner: ----
Status: Submitted (was: New)
Status: Released (was: Submitted)
Status: New (was: Released)
I'm slightly confused by the labels and state changes of the issue :) Should this work on current master? As reported on the mailing list:

We're using the gitiles plugin. Clicking (browse) in the repository list view (or on a specific branch in the branch list) brings me to the correct gitiles page. However when using (browse) on any change/commit directs to a wrong URL

e.g. it generates


where it should have been


I am on current master (from today morning) with current gitiles plugin (not much happening there anyway :)). I did NOT set any URL configs, etc. up until now.
Status: Accepted (was: New)
I've just tested it on the latest master branch of the plugin against gerrit stable-2.16, and it doesn't work. 
As far as I can see, the plugin is generating the correct URL, i.e. "/plugins/gitiles/project/+/sha1" but in the PG UI it ends up with "/c/".
In other words, this will affect all plugins that implement the weblinks interface, not only gitiles.

Labels: Blocking-2.16
Project Member

Comment 40 by, Nov 13

Project Member

Comment 41 by, Nov 13

Status: ChangeUnderReview (was: Accepted)
Project Member

Comment 42 by, Nov 14

Status: Submitted (was: ChangeUnderReview)
Project Member

Comment 43 by, Nov 20

Labels: FixedIn-2.16
Status: Released (was: Submitted)

Sign in to add a comment