Re: Having postgresql.org link to cgit instead of gitweb

Поиск
Список
Период
Сортировка
От Álvaro Herrera
Тема Re: Having postgresql.org link to cgit instead of gitweb
Дата
Msg-id 202509190810.xjzlrepflidb@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Having postgresql.org link to cgit instead of gitweb  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Having postgresql.org link to cgit instead of gitweb
Список pgsql-hackers
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/



В списке pgsql-hackers по дате отправления: