Agreed, the basic loop is cron, git rebase and a model call, and that's roughly where this started. Most of the work went into the checks around it: running the tests on both the release and the moved copy, so a failure upstream already has doesn't block you; not dropping a patch as "already upstream" without evidence; and a final check that every hunk is still there after the model's rewrite (the benchmark caught a case where it silently dropped some). If your script does those, you don't need this. Out of curiosity, what made you stop maintaining yours: keeping the script working, or conflicts the model got wrong?
this is something that can be done with a cron, script, and LLM when conflicts happen - without the middleman needing to make a profit
this is how I have done it in the past anyhow (before project abandonment)
Agreed, the basic loop is cron, git rebase and a model call, and that's roughly where this started. Most of the work went into the checks around it: running the tests on both the release and the moved copy, so a failure upstream already has doesn't block you; not dropping a patch as "already upstream" without evidence; and a final check that every hunk is still there after the model's rewrite (the benchmark caught a case where it silently dropped some). If your script does those, you don't need this. Out of curiosity, what made you stop maintaining yours: keeping the script working, or conflicts the model got wrong?
stopped using the upstream project altogether, or the changes landed upstream
maintaining patches is generally not something you want to be doing
[flagged]
[flagged]