Hacker News Reader

Comment by estimator7292 | Hacker News Reader

I'm still holding out hope for distributed and federated git forges. The only compelling reason for everyone to centralize on GitHub is collaboration on issues/PRs without everyone allowing signups on their self-hosted forges. That could be achieved without hosting every line of code everyone's ever written in the same crumbling infrastructure.

It'll probably never happen. But it'd be really nice if it did.

View on HN

Jeremie (of XMPP) has a neat project, v-it, which uses atproto (Bluesky) to let people socialize their changes to projects. https://v-it.org/

It's a bit short of actual PRs, but in some ways, especially with agents, the lo-fi approach has some advantages.

Interesting project, thanx.

Also nice language evolutions: "socialize their changes to projects", "lo-fi approach" :)

> I'm still holding out hope for distributed and federated git forges.

Do you know that you can just send a patch via email (assuming you're not using the gmail web client)? You can even save the diff on some hosting website and send the link via any text medium.

I say this as someone who actually ran mailservers for about 25 years, who can telnet to port 25 and type SMTP to send an email, and who is hugely found of plaintext: I'd rather quit coding than move to that workflow. I loathe every bit of the pipeline of getting a clean patch from machine A to machine B, where I control at most one of them, and having it come out the other side with the same SHA256 digest. I don't look down on people who prefer it: to each their own! But I'll never in a million years understand it. Say what you will about the GitHub-style PR process, and there's plenty to say about it!, but there's a reason that devs outside LKML and the *BSD mailing lists pretty much immediately leapt onto GitHub the moment it became widely known. It was a revelation.

I get your point and maybe my tone was snarky (not a native speaker). But why would you want an exact reproduction on the other side? The diff format is human-readable for a reason, so slight errors can be fixed quite easily (if they do happen). Extracting patches from a well-configured MUA can be done quickly too.

In this workflow, I don't think it's meant to have the same SHA1 digest. It's a workflow that's very much designed for a handful of core contributors (who have direct repository access) and gatekept one-off patches.

Some other accepted git workflows, like rebasing onto master, or even adding a "committed-by" or "signed-off-by", don't preserve SHA1 hashes either, and it seems you don't really need that property outside of closely collaborating cliques.

Reply on news.ycombinator.com