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)
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 jj on the client-side. It seems perfectly suited for the no-named-branches workflow.
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 :)
Attention: We currently advise against upgrading to Forgejo 17.0.0. An issue is currently being investigated that prevents pushing, merging, or other code operations in some cases.
If you haven't updated yet, please wait until the issue has been investigated more thoroughly, if possible.
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.
Often the idea is to have some entry pages not behind mitigations (but maybe cached for longer).
Some kind of interface where Forgejo can tell the frontend "this query is of the expensive type" would be nice (it would also work to have the frontend tell Forgejo "if you consider this too expensive, forward the request to {url}, the tar pit").
That way the frontend doesn't have to know all the 100 ways how diffs can be requested, it simply knows "not an authenticated request, expensive, high load → Anubis", and Forgejo doesn't have to reinvent the mitigations itself.
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.
oliverpool | 17 hours ago
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)
wjt | 13 hours ago
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.oliverpool | 11 hours ago
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
pgeorgi | 7 hours ago
https://floss.social/@forgejo/117450533397721524 says (even though it's currently behind "429 too many requests" when linking directly, but it's accessible via https://floss.social/@forgejo):
Also on https://codeberg.org/forgejo/forgejo/releases, but missing in a couple more obvious places (like the release page)
gcupc | 7 hours ago
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.
technomancy | 6 hours ago
What would the benefit be to making it built-in to Forgejo instead of general-purpose and reusable?
oliverpool | 5 hours ago
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.
pgeorgi | 5 hours ago
Often the idea is to have some entry pages not behind mitigations (but maybe cached for longer).
Some kind of interface where Forgejo can tell the frontend "this query is of the expensive type" would be nice (it would also work to have the frontend tell Forgejo "if you consider this too expensive, forward the request to {url}, the tar pit").
That way the frontend doesn't have to know all the 100 ways how diffs can be requested, it simply knows "not an authenticated request, expensive, high load → Anubis", and Forgejo doesn't have to reinvent the mitigations itself.
gcupc | 3 hours ago
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.