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 по дате отправления: