- cross-posted to:
- selfhosted@lemmy.world
- cross-posted to:
- selfhosted@lemmy.world
lobsters score: 1 · tags: release, vcs
You must log in or register to comment.
The Forgejo feature that would be most useful to me would be some kind of scraper mitigation. I may have missed something, but I am having to do mitigations at the level of the web server that is proxying it.
score 1 · canonical
What would the benefit be to making it built-in to Forgejo instead of general-purpose and reusable?
score 1 · canonical
Mainly that Forgejo has a lot of GET endpoints that are both expensive, and discoverable by crawling. Bots crawling Forgejo are a much bigger contributor to my homeserver’s overwhelming IO load than anything else on the server. Which is not to say that I wouldn’t also put mitigations on the web server side.
score 1 · canonical
Forgejo should know best which endpoints are expensive and if a user is authenticated (to rate-limit if needed).
So having it builtin would simplify the deployment and be more precise.
score 1 · canonical
Contributed to AGit push feature and the documentation rewrite. Happy to answer any question about it ! (I still have some ideas about further improvements, but this is already a big milestone)
score 1 · canonical
How does it interact with Git LFS?
GitHub has a sort of mirror-image feature where, when creating a PR from a fork to upstream, the PR creator can allow upstream maintainers to push changes back to the PR’s source branch in the fork. However, this does not work correctly if Git LFS is involved. My understanding is that the issue is that, while the git push permission is scoped to the PR’s source branch, pushing LFS objects back to the fork is all-or-nothing, so GitHub chooses nothing rather than allowing upstream to balloon the fork’s LFS storage. (Basically once an object is in LFS you can never safely remove it, lest some old ref point to it.) This is super-annoying for our open-source game where the maintainers routinely need to fix miscellaneous issues in less-experienced contributors’ PRs prior to merge.
IIUC the AGit flow is conceptually reversed: a contributor without general write access to the upstream repo can push to specific refs in the upstream repo. Can they also push Git LFS objects? If so, how do you avoid contributors consuming unbounded LFS storage in the upstream? If not, … alas, it was a wonderful dream. :)
Edit: and I’d love to see someone document how to use the AGit flow with
jjon the client-side. It seems perfectly suited for the no-named-branches workflow.
score 1 · canonical
Agit should work over ssh with git lfs (I could only find issues with http). I did not change anything here, but I know that LFS changes are being made.
git lfs objects impacts the storage like normal git objects (even though the underlying storage may have another quota).
In Forgejo (unlike github afaik) forks completely duplicate this storage. Having Agit PR (unlike fork-based PRs) allows to prevent this useless duplication (from a hoster point of view).
From a repo owner point of view, it balloons the storage (like a fork-based PR), but since you are now allowed to (force) push to the PR, you should be able to cleanup those objects (from LFS as well once they have been made unreachable).
I am not well versed into the LFS topic and I think it would be great if you could give this a try and report your experience ! https://v16.next.forgejo.org/ (if you plan to upload a large repo, please ping in matrix first, to not get banned :)
JJ does not support agit at all yet: https://github.com/jj-vcs/jj/issues/4388
score 1 · canonical