On Apr 4, 2025, Richard Stallman <r...@gnu.org> wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>> 2. >> - git clone the project's repository (presumably already done, it's a >> maintainer after all) >> - check out the target branch (possibly already done, same reason) >> - git pull to fetch the PR and merge it >> - review the changes >> - git push to the project's repository >> 3. >> - review the proposed changes >> - click on the "merge" button > The answer for (3) seems to describe operations at the user interface > level. But the answer for (2) describes them at the level of > computational tasks. That is a reasonable interpretation, but no, both describe user interface operations and computational tasks. That 3. is so much leaner is presumably the reason for some people to prefer it: downloading a repo, checking it out, and fetching the proposed changes can be quite slow and network- and disk-intensive operations. Integrating it with a convenient interface would only make it mostly seamless by avoiding all the heavy network and disk latency, as I suggested: having the repo and PR database *already* downloaded onto the user's computer (e.g. through Jami's gossip protocol). git-ssb had something along these lines, including the button to merge PRs by pushing a single button. Then it can be as instant on the user side as what existing forges do server-side. > Maybe the only real difference is that in (2) those operations > are supposed to be one in your machine, whereas in (3) the machine > that is running the web server does them. Is that it? Mostly. Most of the delay arises when the machine that does the computing is not the one where the data lives at rest. > Perhaps this could be addressed by a browser add-on that you load > into your browser before handling pull requests. Could that do > the operations in (2) while making them look like (3)? The inconvenient latency cannot be hidden except by keeping the data close to the computing. Fortunately, git was *made* to enable such client-side operations. But pulling from other's repos adds a slow step, and pushing to the "central" repo afterwards creates races that may require merges to be repeated and retried. The way to avoid this kind of inconvenience would be to keep repositories and PRs live-replicated on users' computers, and using an interface that, with a single button push, checked with other replicas that the branch hasn't moved, locking it so that it doesn't move until the PR merge is pushed, then performed the merge with the already-downloaded PR and propagated it to other replicas, releasing the lock. This is what centralized servers accomplish, but without the coordination required for distributed locks. That complication (and that of dangling locks after network outages) can be avoided by trying the PR merge and, in case the push fails because someone beat us to it, fetching the third-party updates and retrying to merge on top of them, until the push succeeds. In projects with high commit contention, the retries could take a long time to succeed. It's far from trivial. -- Alexandre Oliva, happy hacker https://blog.lx.oliva.nom.br/ Free Software Activist FSFLA co-founder GNU Toolchain Engineer Learn the truth about Richard Stallman at https://stallmansupport.org/
