Last modified: 2014-02-13 19:31:40 UTC
gitweb URL should be rewritten so that they still work when we switch to GitBlit: we really don't want to update thousands of URLs on mediawiki.org alone, not to mentions all the places we can't update.
Ideally, also rewrite (some) old SVN URLs to deprecated/deleted directories: perhaps with GitBlit it will be easier, as I hear it has tree views to which we could at least fallback if there's not the specific thing one was looking for/has been redirected to.
Chad said on bug 38383 that he's working on this.
I've updated links on the most important templates: <https://www.mediawiki.org/w/index.php?title=Special:Contributions/Nemo_bis&dir=prev&offset=20130605202439&limit=4&target=Nemo+bis>
Example patterns to cover, from current links:
Also the [[m:Interwiki map]] of course: MZ, can you update it?
(In reply to comment #2)
> Also the [[m:Interwiki map]] of course: MZ, can you update it?
I'd be happy to, I'm just not sure exactly what should be changed.
Swap the Git entry from:
To something like:
(In reply to comment #0)
> Ideally, also rewrite (some) old SVN URLs to deprecated/deleted directories:
> perhaps with GitBlit it will be easier, as I hear it has tree views to which
> could at least fallback if there's not the specific thing one was looking
> for/has been redirected to.
Wasn't planning to rewrite the SVN urls, since SVN is going to still exist as r/o.
https://gerrit.wikimedia.org/r/#/c/68110/ for LocalisationUpdate MediaWiki core was done.
For the rest, I understand some help would be needed with regex rules.
Related URL: https://gerrit.wikimedia.org/r/70370 (Gerrit Change If02ce0fe0ddd8a9b692a0d2526bdbed27a762fc4)
*** Bug 50398 has been marked as a duplicate of this bug. ***
Can we write a small redirector at https://gerrit.wikimedia.org/r/gitweb instead of a bunch of adhoc rewrite rules?
(In reply to comment #9)
> Can we write a small redirector at https://gerrit.wikimedia.org/r/gitweb
> instead of a bunch of adhoc rewrite rules?
It can be added after all the other redirects to catch the URLs which didn't match previous rewrites, I suppose.
Change 70370 merged by Ryan Lane:
Rewrite gerrit gitweb URLs to new gitblit
Thanks S for the patch, and thanks Ryan for the merge.
Thanks indeed, do we have an estimate of how many of those mediawiki.org links are still broken? I see several which either don't redirect or redirect to the git.wm.o root; some can't be replaced (like grepping URLs) but most potentially could IIRC.
Only links I still see are: https://www.mediawiki.org/w/index.php?title=Special%3ALinkSearch&target=gerrit.wikimedia.org%2Fr%2Fgitweb
They can probably be fixed manually.
Are there others you're seeing?
See the links in comment 1 for 753+8 links as of now (they were about 1500 after the first template fixes IIRC).
FYI, Redirect rules: https://git.wikimedia.org/blob/operations%2Fpuppet.git/3c9c28f2c869c3eee471d9bf4aced12c3de9a039/templates%2Fapache%2Fsites%2Fgerrit.wikimedia.org.erb
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git is pretty simple and currently broken. It redirects:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git => https://git.wikimedia.org/summary/mediawiki%252fcore%252egit/HEAD => http://git.wikimedia.org/
It would be nice to get that working.
(In reply to comment #17)
gitblit required '/' in project paths be changed to %2F, so my Apache mod_rewrite rules triggered URL-encoding. This worked for a while, but now the %2F is getting URL-encoded a second time which turns the '%' into %25, and gitblit chokes on the resulting %25%2f.
I suspect Christian Aistleitner's puppet commit f5a3b40b on Jun 29, which changed AllowEncodedSlashes from NoDecode to On, probably caused the break. (Despite my copious comments as to why it needs to be that way :-) .)
I notice gitblit's own URLs to summaries are much simpler now, instead of the URL-encoded slashes after summary it is just
That's probably simpler to implement in an Apache mod_rewrite rule rather than this fragile setup of URL-encoding exactly once. I don't know if there's a simpler format for linking to a file within a project, the same rewrite rules also used to rewrite to
which now has %25%2f s and is likewise broken.
Chad, are gitblit URLs documented anywhere?
Not to my knowledge
Christian Aistleitner points out his check-in long predated mine (d'oh, sorry), so that isn't what changed; but while testing on my local Apache I did have to set AllowEncodedSlashes to NoDecode even though it was never in my patch. Someone could try this in the config, I don't know what else it would break.
The confusion was caused by the rebase. In patch set 1 of S's patch (https://gerrit.wikimedia.org/r/#/c/70370/1/templates/apache/sites/gerrit.wikimedia.org.erb), NoDecode was on in both sides. In patch set 2 (after rebase), it was "AllowEncodedSlashes On" on both sides (https://gerrit.wikimedia.org/r/#/c/70370/2/templates/apache/sites/gerrit.wikimedia.org.erb).
Change 82044 had a related patch set uploaded by QChris:
Fix double encoded characters in gitweb -> gitblit forwards
Change 82044 merged by Ottomata:
Fix double encoded characters in gitweb -> gitblit forwards
The test cases at https://git.wikimedia.org/blob/operations%2Fpuppet.git/3c9c28f2c869c3eee471d9bf4aced12c3de9a039/templates%2Fapache%2Fsites%2Fgerrit.wikimedia.org.erb#L98 all work again, yay!
In reply to comment #18
> That's probably simpler to implement in an Apache mod_rewrite rule rather
> this fragile setup of URL-encoding exactly once.
Until we figure out if there's also a simpler query string URL for linking to project files, we should stick to this complex but consistent approach.
For the records, the LinkSearch queries of comment 1 now find "only" 463+8 links. I've not counted how many work.
This redirects to https://git.wikimedia.org/summary/mediawiki%2fcore%2egit/HEAD which isn't the expected behavior.
Tentatively re-opening this bug as I'm not sure this it's resolved/fixed.