Having postgresql.org link to cgit instead of gitweb
Hi,
While prepping the website for the PG18 GA, I stumbled on the inability
to access parts of commits through the gitweb links, specifically
hitting 429 status code errors (this seems to be intermittent). After
some briefing on why it's disabled and how this isn't an issue with
cgit, I prepped a patch for postgresql.org (the main website) that would
update the git.postgresql.org reference to use cgit instead of gitweb.
However, as this could impact some hacker workflows (e.g. the commit
search page), I wanted to run this patch by -hackers before committing.
Basically, the patch:
* Moves any web links to git.postgresql.org repos to use the cgit
interface instead of gitweb (e.g. [1]https://www.postgresql.org/developer/related-projects/)
* Update the commit search[2]https://www.postgresql.org/developer/coding/ to use cgit instead of gitweb
Please note that this doesn't impact the availability of gitweb, rather
the main parts of the postgresql.org website will link to cgit first,
and people will have a more consistent experience overall (e.g. no 429
errors).
Thoughts?
Thanks,
Jonathan
[1]: https://www.postgresql.org/developer/related-projects/
[2]: https://www.postgresql.org/developer/coding/
Attachments:
0001-Move-gitweb-links-to-cgit.patchtext/plain; charset=UTF-8; name=0001-Move-gitweb-links-to-cgit.patchDownload
From c3d8523951c6736e55da870ab622cc0c34d57011 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Thu, 18 Sep 2025 21:02:40 -0400
Subject: [PATCH] Move gitweb links to cgit
Parts of the gitweb functionality are no longer accessible,
specifically viewing individual commits. cgit doesn't have this
issue, thus move the website links to use the cgit interface.
---
pgweb/core/templatetags/pgfilters.py | 2 +-
templates/docs/docspage.html | 2 +-
templates/pages/about/governance.html | 2 +-
.../pages/about/governance/sysadmin.html | 2 +-
.../pages/about/policies/conferences.html | 2 +-
templates/pages/about/policies/npos.html | 2 +-
templates/pages/developer/backend.html | 24 +++++++++----------
templates/pages/developer/coding.html | 8 +++----
templates/pages/developer/committers.html | 2 +-
.../corereports/january2022_december2022.html | 2 +-
.../pages/developer/related-projects.html | 18 +++++++-------
templates/pages/download.html | 2 +-
12 files changed, 33 insertions(+), 35 deletions(-)
diff --git a/pgweb/core/templatetags/pgfilters.py b/pgweb/core/templatetags/pgfilters.py
index d66630d..8e038e0 100644
--- a/pgweb/core/templatetags/pgfilters.py
+++ b/pgweb/core/templatetags/pgfilters.py
@@ -151,7 +151,7 @@ def languagename(lang):
@register.simple_tag(takes_context=True)
def git_changes_link(context):
- return mark_safe('<a href="https://git.postgresql.org/gitweb/?p=pgweb.git;a=history;f=templates/{}">View</a> change history.'.format(context.template_name))
+ return mark_safe('<a href="https://git.postgresql.org/cgit/pgweb.git/log/templates/{}">View</a> change history.'.format(context.template_name))
# CSS inlining (used for HTML email)
diff --git a/templates/docs/docspage.html b/templates/docs/docspage.html
index f19cb0c..bad2e87 100644
--- a/templates/docs/docspage.html
+++ b/templates/docs/docspage.html
@@ -18,7 +18,7 @@
<div class="row">
<div class="col">
<div>
- <a href="/docs/" title="Documentation">Documentation</a> → <a href="/docs/{{page.display_version}}/{{doc_index_filename}}">PostgreSQL {{page.display_version}}</a>{%if loaddate%} ({{loaddate|date:"Y-m-d H:i:s"}}{%if loadgit%} - git commit <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h={{loadgit}}">{{loadgit}}</a>{%endif%}){%endif%}
+ <a href="/docs/" title="Documentation">Documentation</a> → <a href="/docs/{{page.display_version}}/{{doc_index_filename}}">PostgreSQL {{page.display_version}}</a>{%if loaddate%} ({{loaddate|date:"Y-m-d H:i:s"}}{%if loadgit%} - git commit <a href="https://git.postgresql.org/cgit/postgresql.git/commit/?id={{loadgit}}">{{loadgit}}</a>{%endif%}){%endif%}
</div>
</div>
</div>
diff --git a/templates/pages/about/governance.html b/templates/pages/about/governance.html
index b838a3c..c49620d 100644
--- a/templates/pages/about/governance.html
+++ b/templates/pages/about/governance.html
@@ -28,7 +28,7 @@ and charter.
<p>
The <a href="/developer/committers/">PostgreSQL Committers</a>
are the people with access to push to the
- <a href="https://git.postgresql.org/gitweb/?p=postgresql.git">git repository</a>.
+ <a href="https://git.postgresql.org/cgit/postgresql.git/">git repository</a>.
</p>
<h2>Security Team</h2>
diff --git a/templates/pages/about/governance/sysadmin.html b/templates/pages/about/governance/sysadmin.html
index 0e48f20..5fde2c2 100644
--- a/templates/pages/about/governance/sysadmin.html
+++ b/templates/pages/about/governance/sysadmin.html
@@ -11,7 +11,7 @@
is discussed on the
<a href="http://archives.postgresql.org/pgsql-www/">pgsql-www mailing list</a>.
Source code for the postgresql.org web site is stored in a public
- <a href="https://git.postgresql.org/gitweb/?p=pgweb.git;a=summary">GIT repository</a>.
+ <a href="https://git.postgresql.org/cgit/pgweb.git/">GIT repository</a>.
</p>
<h2>Infrastructure Team Members</h2>
diff --git a/templates/pages/about/policies/conferences.html b/templates/pages/about/policies/conferences.html
index ca5a8b4..a440805 100644
--- a/templates/pages/about/policies/conferences.html
+++ b/templates/pages/about/policies/conferences.html
@@ -5,7 +5,7 @@
<h1>Community Conference Recognition <i class="fas fa-gavel"></i></h1>
-<p><em>Last updated: September 21, 2023. {%git_changes_link%} <a href="https://git.postgresql.org/gitweb/?p=pgweb.git;a=history;f=templates/pages/community/recognition.html">View</a> history before December 8, 2020.</em></p>
+<p><em>Last updated: September 21, 2023. {%git_changes_link%} <a href="https://git.postgresql.org/cgit/pgweb.git/log/templates/pages/community/recognition.html">View</a> history before December 8, 2020.</em></p>
<p>The Community Conference Recognition programme is a voluntary scheme under which submitters of events to the <a href="/about/events/">PostgreSQL Website listings</a> may self-assess their entry against the criteria below, and if they comply may market their event as a PostgreSQL Community event.</p>
diff --git a/templates/pages/about/policies/npos.html b/templates/pages/about/policies/npos.html
index cc8ac37..303dba1 100644
--- a/templates/pages/about/policies/npos.html
+++ b/templates/pages/about/policies/npos.html
@@ -5,7 +5,7 @@
<h1>Recognised PostgreSQL Nonprofit Organisations <i class="fas fa-gavel"></i></h1>
-<p><em>Last updated: January 7, 2025. {%git_changes_link%} <a href="https://git.postgresql.org/gitweb/?p=pgweb.git;a=history;f=templates/pages/community/recognition.html">View</a> history before December 8, 2020.</em></p>
+<p><em>Last updated: January 7, 2025. {%git_changes_link%} <a href="https://git.postgresql.org/cgit/pgweb.git/log/templates/pages/community/recognition.html">View</a> history before December 8, 2020.</em></p>
<p>Recognised PostgreSQL Nonprofit Organisations (NPOs) will be listed on the <a href="/community/recognised-npos/">PostgreSQL Website</a> as such. To become recognised as an NPO, the organisation must self-certify that they meet the criteria below, aimed at ensuring they meet the standards of openness expected in the PostgreSQL Community.
</p>
diff --git a/templates/pages/developer/backend.html b/templates/pages/developer/backend.html
index a556644..38ff210 100644
--- a/templates/pages/developer/backend.html
+++ b/templates/pages/developer/backend.html
@@ -46,14 +46,14 @@ echo "0, 0," | awk -F, '{printf "%d, %d\n", $1 + 145, $2 + 45}'
or Unix Domain sockets. It is loaded into a string, and passed to the <a
href="https://wiki.postgresql.org/wiki/Backend_flowchart#parser">parser,</a>
where the lexical scanner, <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/scan.l">scan.l,</a>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/parser/scan.l">scan.l,</a>
breaks the query up into tokens(words). The parser uses <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y">gram.y</a>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/parser/gram.y">gram.y</a>
and the tokens to identify the query type, and load the proper
query-specific structure, like <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h">CreateStmt</a>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/include/nodes/parsenodes.h">CreateStmt</a>
or <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h">SelectStmt.</a></p>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/include/nodes/parsenodes.h">SelectStmt.</a></p>
<p>The statement is then identified as complex (<em>SELECT / INSERT /
UPDATE / DELETE</em>) or simple, e.g <em>CREATE ROLE, ANALYZE,</em>
@@ -62,27 +62,27 @@ functions in the <a href="https://wiki.postgresql.org/wiki/Backend_flowchart#com
Complex statements require more handling.</p>
<p>The parser takes a complex query, and creates a <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h">Query</a>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/include/nodes/parsenodes.h">Query</a>
structure that contains all the elements used by complex queries.
Query.jointree holds the <em>FROM</em> and <em>WHERE</em> clauses, which is filled
in by <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/parse_clause.c">transformFromClause()</a> and
-<a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/parse_clause.c">transformWhereClause().</a>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/parser/parse_clause.c">transformFromClause()</a> and
+<a href="https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/parser/parse_clause.c">transformWhereClause().</a>
Each table referenced in the query is represented by a <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h">RangeTblEntry,</a>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/include/nodes/parsenodes.h">RangeTblEntry,</a>
and they are linked together to form the <em>range table</em> of the
query, which is generated by <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/parse_clause.c">transformFromClause().</a>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/parser/parse_clause.c">transformFromClause().</a>
Query.rtable holds the query's range table.</p>
<p>Certain queries, like <em>SELECT,</em> return columns of data. Other
queries, like <em>INSERT</em> and <em>UPDATE,</em> specify the columns
modified by the query. These column references are converted to <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/primnodes.h">TargetEntry</a>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/include/nodes/primnodes.h">TargetEntry</a>
entries, which are linked together to make up the <em>target list</em> of
the query. The target list is stored in Query.targetList, which is
generated by <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/parse_target.c">transformTargetList().</a></p>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/parser/parse_target.c">transformTargetList().</a></p>
<p>Other query elements, like aggregates(<em>SUM()</em>), <em>GROUP
BY,</em> and <em>ORDER BY</em> are also stored in their own Query
@@ -100,7 +100,7 @@ type of each table in the RangeTable, using Query.jointree(<em>FROM</em>
and <em>WHERE</em> clauses) to consider optimal index usage.</p> The <a
href="https://wiki.postgresql.org/wiki/Backend_flowchart#optimizer_path">path</a>
module then generates an optimal <a
-href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/plannodes.h">Plan,</a>
+href="https://git.postgresql.org/cgit/postgresql.git/tree/src/include/nodes/plannodes.h">Plan,</a>
which contains the operations to be performed to execute the query.</p>
<p>The Plan is then passed to the <a
diff --git a/templates/pages/developer/coding.html b/templates/pages/developer/coding.html
index 594abbf..0cce4d6 100644
--- a/templates/pages/developer/coding.html
+++ b/templates/pages/developer/coding.html
@@ -8,7 +8,7 @@
<h2>Code access and information</h2>
<ul>
- <li><a href="https://git.postgresql.org/gitweb?p=postgresql.git">Web interface to the Source Code Repository</a></li>
+ <li><a href="https://git.postgresql.org/cgit/postgresql.git/">Web interface to the Source Code Repository</a></li>
<li><a href="/docs/current/git.html">Information about the Source Code Repository</a></li>
<li><a href="https://doxygen.postgresql.org/">Source Code Browser</a> (Doxygen)</li>
<li><a href="/developer/backend/">Backend Flowchart</a></li>
@@ -19,11 +19,9 @@
<h2>Search Code By Git Commit Hash</h2>
<div class="row">
<div class="col-6">
- <form action="https://git.postgresql.org/gitweb" method="get">
- <input type="hidden" name="p" value="postgresql.git" />
- <input type="hidden" name="a" value="commitdiff" />
+ <form action="https://git.postgresql.org/cgit/postgresql.git/commit/" method="get">
<div class="input-group">
- <input class="form-control" type="text" name="h" type="text" size="40" placeholder="e.g. "861861edcc04a6e3ebdfe363311f122e2b226196"">
+ <input class="form-control" type="text" name="id" size="40" placeholder="e.g. "861861edcc04a6e3ebdfe363311f122e2b226196"">
<span class="input-group-btn">
<button class="btn btn-default" type="submit"><i class="fas fa-search"></i></button>
</span>
diff --git a/templates/pages/developer/committers.html b/templates/pages/developer/committers.html
index f9dad20..f11814b 100644
--- a/templates/pages/developer/committers.html
+++ b/templates/pages/developer/committers.html
@@ -6,7 +6,7 @@
<p>
This is the current list of people with access to push to the
- <a href="https://git.postgresql.org/gitweb/?p=postgresql.git">git repository</a>.
+ <a href="https://git.postgresql.org/cgit/postgresql.git/">git repository</a>.
For technical details on how committing works, see
<a href="https://wiki.postgresql.org/wiki/Committing_with_Git">Committing with Git</a>.
This is just a list of people who currently have access to push to git; for
diff --git a/templates/pages/developer/corereports/january2022_december2022.html b/templates/pages/developer/corereports/january2022_december2022.html
index fca8251..e7412c2 100644
--- a/templates/pages/developer/corereports/january2022_december2022.html
+++ b/templates/pages/developer/corereports/january2022_december2022.html
@@ -17,7 +17,7 @@
<p>
The PostgreSQL Core Team accepted changes to the Code of Conduct to
clarify
- <a href="https://git.postgresql.org/gitweb/?p=pgweb.git;a=commitdiff;h=76ea6e51d7e74e93f82b93630e10da51906e1a4d;hp=de0364bf011eae2eecf74075ab8e3be6c6a7e608">
+ <a href="https://git.postgresql.org/cgit/pgweb.git/commit/?id=76ea6e51d7e74e93f82b93630e10da51906e1a4d">
term limits</a>.
</p>
</li>
diff --git a/templates/pages/developer/related-projects.html b/templates/pages/developer/related-projects.html
index 2131354..83579b1 100644
--- a/templates/pages/developer/related-projects.html
+++ b/templates/pages/developer/related-projects.html
@@ -37,8 +37,8 @@
The PostgreSQL website is split into a dynamic and static part:
</p>
<ul>
- <li><a href="https://git.postgresql.org/gitweb/?p=pgweb.git;a=summary">Dynamic content repository</a></li>
- <li><a href="https://git.postgresql.org/gitweb/?p=pgweb-static.git;a=summary">Static files repository</a></li>
+ <li><a href="https://git.postgresql.org/cgit/pgweb.git/">Dynamic content repository</a></li>
+ <li><a href="https://git.postgresql.org/cgit/pgweb-static.git/">Static files repository</a></li>
</ul>
<p>
The site itself runs on the <a href="https://www.djangoproject.com/">Django</a>
@@ -56,7 +56,7 @@
with moderation.
</p>
<ul>
- <li><a href="https://git.postgresql.org/gitweb/?p=hamn.git;a=summary">Planet PostgreSQL repository</a></li>
+ <li><a href="https://git.postgresql.org/cgit/hamn.git/">Planet PostgreSQL repository</a></li>
<li><a href="https://planet.postgresql.org">Planet PostgreSQL</a></li>
</ul>
<p>
@@ -72,7 +72,7 @@
The PostgreSQL mailing list system is powered by "pglister":
</p>
<ul>
- <li><a href="https://git.postgresql.org/gitweb/?p=pglister.git;a=summary">pglister main repository</a></li>
+ <li><a href="https://git.postgresql.org/cgit/pglister.git/">pglister main repository</a></li>
<li><a href="https://lists.postgresql.org/">Mailing lists</a></li>
</ul>
@@ -83,7 +83,7 @@
the PostgreSQL project.
</p>
<ul>
- <li><a href="https://git.postgresql.org/gitweb/?p=pgarchives.git;a=summary">pgarchives main repository</a></li>
+ <li><a href="https://git.postgresql.org/cgit/pgarchives.git/">pgarchives main repository</a></li>
<li><a href="https://www.postgresql.org/list/">Mailing list archives</a></li>
</ul>
<p>
@@ -115,7 +115,7 @@
</p>
<ul>
<li><a href="https://commitfest.postgresql.org/">Commitfest website</a></li>
- <li><a href="https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=summary">pgcommitfest main repository</a></li>
+ <li><a href="https://git.postgresql.org/cgit/pgcommitfest2.git/">pgcommitfest main repository</a></li>
</ul>
<p>
You can get involved in this project by communicating on
@@ -195,13 +195,13 @@
<li><a href="https://www.bsdcan.org/">BSDCan - The BSD Conference</a></li>
</ul>
<p>
- The conference system runs on the <a href="https://www.djangoproject.com/">django web framework</a>, and is Open Source with a <a href="https://git.postgresql.org/gitweb/?p=pgeu-system.git;a=blob_plain;f=LICENSE;hb=HEAD">MIT License</a>.
+ The conference system runs on the <a href="https://www.djangoproject.com/">django web framework</a>, and is Open Source with a <a href="https://git.postgresql.org/cgit/pgeu-system.git/plain/LICENSE">MIT License</a>.
</p>
<p>
The code is hosted on git.postgresql.org, and mirrored to GitHub:
</p>
<ul>
- <li><a href="https://git.postgresql.org/gitweb/?p=pgeu-system.git;a=summary">pgeu-system main repository</a></li>
+ <li><a href="https://git.postgresql.org/cgit/pgeu-system.git/">pgeu-system main repository</a></li>
<li><a href="https://github.com/pgeu/pgeu-system">GitHub mirror</a></li>
</ul>
<p>
@@ -221,7 +221,7 @@
minor updates.
</p>
<ul>
- <li><a href="https://git.postgresql.org/gitweb/?p=press.git;a=summary">Press Kit repository</a></li>
+ <li><a href="https://git.postgresql.org/cgit/press.git/">Press Kit repository</a></li>
</ul>
<p>
If you are interested in becoming a press release translator, you can get
diff --git a/templates/pages/download.html b/templates/pages/download.html
index 0e29e0a..6905a42 100644
--- a/templates/pages/download.html
+++ b/templates/pages/download.html
@@ -78,7 +78,7 @@ yourself.
<p>
The source code can be found in the main <a href="/ftp/source/">file browser</a>
or you can access the source control repository directly
-at <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=summary" target="_blank" rel="noopener">git.postgresql.org</a>.
+at <a href="https://git.postgresql.org/cgit/postgresql.git/" target="_blank" rel="noopener">git.postgresql.org</a>.
Instructions for building from source can be found in the
<a href="/docs/current/installation.html">documentation</a>.
</p>
--
2.39.5 (Apple Git-154)
On Fri, 19 Sept 2025 at 13:12, Jonathan S. Katz <jkatz@postgresql.org> wrote:
While prepping the website for the PG18 GA, I stumbled on the inability
to access parts of commits through the gitweb links, specifically
hitting 429 status code errors (this seems to be intermittent). After
some briefing on why it's disabled and how this isn't an issue with
cgit, I prepped a patch for postgresql.org (the main website) that would
update the git.postgresql.org reference to use cgit instead of gitweb.
Please note that this doesn't impact the availability of gitweb, rather
the main parts of the postgresql.org website will link to cgit first,
and people will have a more consistent experience overall (e.g. no 429
errors).
You didn't mention the cause of the specific issues, but it has been
mentioned on www lists before, so I don't think it's a secret with the
bot traffic. Have you considered if switching these links to cgit
wouldn't just cause the traffic to migrate to cgit, over time? If so,
would you just be moving the problem from one place to another? I
mean, the bots are getting the links from somewhere. I'd imagine
release notes and the likes to be a popular source of links.
Perhaps someone with more knowledge than I have on the problem can
comment to give insight into if the same issue could occur with cgit.
David
On 2025-Sep-19, David Rowley wrote:
You didn't mention the cause of the specific issues, but it has been
mentioned on www lists before, so I don't think it's a secret with the
bot traffic. Have you considered if switching these links to cgit
wouldn't just cause the traffic to migrate to cgit, over time?
I think this will happen, yes. There are two problems here actually:
the first one is that the old gitweb program, implemented in Perl, is
awfully slow itself. Git itself is fast enough for most things and I
don't think serving its output efficiently, as cgit does, is going to be
a performance problem. So for the `blob` objects, which is what this is
mostly used for, we should be fine with cgit.
The other problem is `git blame`, which can be slow also with pure git,
so if (when) the bots move to run blame with cgit, then we'll be in
trouble just as well, and we're going to need some gating in order to
prevent trouble. However, `blame` hasn't been as much of a problem as
`blob` has, so we can take this more leisurely.
There are two things we could do. One is to simply restrict `git blame`
to authenticated users; this shouldn't be _too_ bad. But if we don't
want that, we could put the bot checker javascript tricks in front of
`blame`. In fact maybe we could have the best of both worlds: you get
the javascript check if you're not authenticated, but nothing if you
are. I'm not sure how easy it is to implement this though.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
On 19.09.25 03:12, Jonathan S. Katz wrote:
* Moves any web links to git.postgresql.org repos to use the cgit
interface instead of gitweb (e.g. [1])
* Update the commit search[2] to use cgit instead of gitweb
If we're doing that -- which seems reasonable -- then perhaps also
update the forwarder for the links sent to pgsql-committers, like
https://git.postgresql.org/pg/commitdiff/ed1aad15e09d7d523f4ef413e3c4d410497c8065
This might be related to the second item, not sure.
On 19.09.25 10:22, Álvaro Herrera wrote:
There are two things we could do. One is to simply restrict `git blame`
to authenticated users; this shouldn't be_too_ bad. But if we don't
want that, we could put the bot checker javascript tricks in front of
`blame`. In fact maybe we could have the best of both worlds: you get
the javascript check if you're not authenticated, but nothing if you
are. I'm not sure how easy it is to implement this though.
Or just disable git blame. Who needs to run that through the website?
On 19 Sep 2025, at 13:05, Peter Eisentraut <peter@eisentraut.org> wrote:
On 19.09.25 10:22, Álvaro Herrera wrote:
There are two things we could do. One is to simply restrict `git blame`
to authenticated users; this shouldn't be_too_ bad. But if we don't
want that, we could put the bot checker javascript tricks in front of
`blame`. In fact maybe we could have the best of both worlds: you get
the javascript check if you're not authenticated, but nothing if you
are. I'm not sure how easy it is to implement this though.Or just disable git blame. Who needs to run that through the website?
We could jut link to the postgres mirror on Github for that.
--
Daniel Gustafsson
On Fri, 19 Sept 2025 at 23:05, Peter Eisentraut <peter@eisentraut.org> wrote:
On 19.09.25 10:22, Álvaro Herrera wrote:
There are two things we could do. One is to simply restrict `git blame`
to authenticated users; this shouldn't be_too_ bad. But if we don't
want that, we could put the bot checker javascript tricks in front of
`blame`. In fact maybe we could have the best of both worlds: you get
the javascript check if you're not authenticated, but nothing if you
are. I'm not sure how easy it is to implement this though.Or just disable git blame. Who needs to run that through the website?
I'd vote for getting rid of the blame if it could buy us back enough
CPU cycles to have diff working again. I personally miss not having
diff. I found it convenient when following links to see what's been
changed from the pgsql-committers list.
David
On 9/19/25 7:42 AM, David Rowley wrote:
On Fri, 19 Sept 2025 at 23:05, Peter Eisentraut <peter@eisentraut.org> wrote:
On 19.09.25 10:22, Álvaro Herrera wrote:
There are two things we could do. One is to simply restrict `git blame`
to authenticated users; this shouldn't be_too_ bad. But if we don't
want that, we could put the bot checker javascript tricks in front of
`blame`. In fact maybe we could have the best of both worlds: you get
the javascript check if you're not authenticated, but nothing if you
are. I'm not sure how easy it is to implement this though.Or just disable git blame. Who needs to run that through the website?
I'd vote for getting rid of the blame if it could buy us back enough
CPU cycles to have diff working again. I personally miss not having
diff. I found it convenient when following links to see what's been
changed from the pgsql-committers list.
With the disclaimer that I'm not the target audience for this work, I've
previously used the "git blame" web feature on git.postgresql.org to
figure some stuff out, but these days I just use the Github one as
Daniel mentioned. I do think the absence of diff is less than ideal, and
definitely something that I use fairly frequently even if I'm not
hacking often.
For the website/patch itself (gitweb vs. cgit), again I'm not the target
audience, so I'll defer to what you all want and particularly want to
ensure your lives are easier. However, with the upcoming traffic spike
with GA, I do want to ensure that our linked things are still working,
which is what prompted the discussion.
Jonathan
On Thu, Sep 18, 2025 at 9:12 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
While prepping the website for the PG18 GA, I stumbled on the inability
to access parts of commits through the gitweb links, specifically
hitting 429 status code errors (this seems to be intermittent). After
some briefing on why it's disabled and how this isn't an issue with
cgit, I prepped a patch for postgresql.org (the main website) that would
update the git.postgresql.org reference to use cgit instead of gitweb.
cgit messes up indentation by showing 8 space tabs (not 4 space tabs)
-- that's certainly not ideal.
I understand that the same problem was fixed within gitweb by patching
the source code.
--
Peter Geoghegan
On 2025-Sep-19, Peter Eisentraut wrote:
On 19.09.25 03:12, Jonathan S. Katz wrote:
* Moves any web links to git.postgresql.org repos to use the cgit
interface instead of gitweb (e.g. [1])
* Update the commit search[2] to use cgit instead of gitwebIf we're doing that -- which seems reasonable -- then perhaps also update
the forwarder for the links sent to pgsql-committers, likehttps://git.postgresql.org/pg/commitdiff/ed1aad15e09d7d523f4ef413e3c4d410497c8065
This might be related to the second item, not sure.
No, I think Jonathan wasn't thinking of these links when he mentioned
that second item. I do have the /pg/commitdiff/ URLs in mind, but
that's a pginfra configuration file that needs to be changed. I'll
see about changing that as well, because I've been bitten by this
problem there too.
BTW regarding Jon's second item, I was again reminded that we have
this "backend flowchart" page there,
https://www.postgresql.org/developer/backend/
I think this is a prime example of something that we could do much
better by adding one more item to our numerous collection of diagrams in
the docbook core docs.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
On 9/19/25 10:47 AM, Álvaro Herrera wrote:
On 2025-Sep-19, Peter Eisentraut wrote:
On 19.09.25 03:12, Jonathan S. Katz wrote:
* Moves any web links to git.postgresql.org repos to use the cgit
interface instead of gitweb (e.g. [1])
* Update the commit search[2] to use cgit instead of gitwebIf we're doing that -- which seems reasonable -- then perhaps also update
the forwarder for the links sent to pgsql-committers, likehttps://git.postgresql.org/pg/commitdiff/ed1aad15e09d7d523f4ef413e3c4d410497c8065
This might be related to the second item, not sure.
No, I think Jonathan wasn't thinking of these links when he mentioned
that second item.
I can confirm that I was thinking about them in the second item; I was
thinking about them though, but was unsure if it needed to be in this
discussion as it isn't directly in the pgweb scope. But holistically, I
guess it does.
I do have the /pg/commitdiff/ URLs in mind, but
that's a pginfra configuration file that needs to be changed. I'll
see about changing that as well, because I've been bitten by this
problem there too.BTW regarding Jon's second item, I was again reminded that we have
this "backend flowchart" page there,
https://www.postgresql.org/developer/backend/
I think this is a prime example of something that we could do much
better by adding one more item to our numerous collection of diagrams in
the docbook core docs.
And we support images now (and for a few releases)!
Jonathan
Peter Geoghegan <pg@bowt.ie> writes:
cgit messes up indentation by showing 8 space tabs (not 4 space tabs)
-- that's certainly not ideal.
To me that seems like a complete blocker for this proposal,
if we can't find a fix.
regards, tom lane
On 9/19/25 12:17 PM, Tom Lane wrote:
Peter Geoghegan <pg@bowt.ie> writes:
cgit messes up indentation by showing 8 space tabs (not 4 space tabs)
-- that's certainly not ideal.To me that seems like a complete blocker for this proposal,
if we can't find a fix.
On a quick read, I believe this is easily settable in the cgit.css file
by setting "tab-size" to "4". I did a quick test hacking this inline,
and it worked.
Further, it appears we already attempt to do this in a "4space.css" file
we serve, but it needs to be edited with the updated cgit HTML/CSS.
Thanks,
Jonathan
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On a quick read, I believe this is easily settable in the cgit.css file
by setting "tab-size" to "4". I did a quick test hacking this inline,
and it worked.
Cool, thanks for looking into it.
regards, tom lane
On 9/19/25 4:14 PM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On a quick read, I believe this is easily settable in the cgit.css file
by setting "tab-size" to "4". I did a quick test hacking this inline,
and it worked.Cool, thanks for looking into it.
Tested inline, but untested as a whole (as I don't have access to
gitweb, nor do I really want to have access), but this is effectively
the modification, the second line of the CSS rule.
Jonathan
Attachments:
On 9/19/25 4:54 PM, Jonathan S. Katz wrote:
On 9/19/25 4:14 PM, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
On a quick read, I believe this is easily settable in the cgit.css file
by setting "tab-size" to "4". I did a quick test hacking this inline,
and it worked.Cool, thanks for looking into it.
Tested inline, but untested as a whole (as I don't have access to
gitweb, nor do I really want to have access), but this is effectively
the modification, the second line of the CSS rule.
If the main concern is lack of diff - which cgit gives us back, and the
main objection is the tab-size patch (in previous email)[1]/messages/by-id/38cfb119-a150-4899-8879-73e3ace66a6a@postgresql.org, is there
any objection to moving forward with updating the URLs after this patch
is applied (which I can't do, as I don't have privileges to that server)?
If there are objections, I'm fine to wait until after the release to
re-open discussion.
Jonathan
[1]: /messages/by-id/38cfb119-a150-4899-8879-73e3ace66a6a@postgresql.org
/messages/by-id/38cfb119-a150-4899-8879-73e3ace66a6a@postgresql.org
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
If the main concern is lack of diff - which cgit gives us back, and the
main objection is the tab-size patch (in previous email)[1], is there
any objection to moving forward with updating the URLs after this patch
is applied (which I can't do, as I don't have privileges to that server)?
Not here.
If there are objections, I'm fine to wait until after the release to
re-open discussion.
My first thought about scheduling was "best not in the middle of the
18.0 release cycle". However, I don't know of any actual connection
between gitweb/cgit and the release-making tasks. My second thought
was "the point here is to cut server load, and maybe we need that to
happen before the anticipated traffic spike on Thursday". There
might not be any connection there either, but if there is, agreed
to get it done sooner not later.
regards, tom lane
On 2025-Sep-22, Tom Lane wrote:
My first thought about scheduling was "best not in the middle of the
18.0 release cycle". However, I don't know of any actual connection
between gitweb/cgit and the release-making tasks. My second thought
was "the point here is to cut server load, and maybe we need that to
happen before the anticipated traffic spike on Thursday". There
might not be any connection there either, but if there is, agreed
to get it done sooner not later.
I think the traffic overloads are mostly caused by LLM scrapers, which
as far as I know does not correlate with spikes caused by human behavior
or even those caused by mirroring traffic during a new release or such.
I would rather wait until next week, just in case something breaks.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"This is what I like so much about PostgreSQL. Most of the surprises
are of the "oh wow! That's cool" Not the "oh shit!" kind. :)"
Scott Marlowe, http://archives.postgresql.org/pgsql-admin/2008-10/msg00152.php
On 9/22/25 11:27 AM, Álvaro Herrera wrote:
On 2025-Sep-22, Tom Lane wrote:
My first thought about scheduling was "best not in the middle of the
18.0 release cycle". However, I don't know of any actual connection
between gitweb/cgit and the release-making tasks. My second thought
was "the point here is to cut server load, and maybe we need that to
happen before the anticipated traffic spike on Thursday". There
might not be any connection there either, but if there is, agreed
to get it done sooner not later.I think the traffic overloads are mostly caused by LLM scrapers, which
as far as I know does not correlate with spikes caused by human behavior
or even those caused by mirroring traffic during a new release or such.I would rather wait until next week, just in case something breaks.
I'm fine with this approach, for the above reasons. The web patch won't
bit shift too much between now and then.
Jonathan