RE: https://metalhead.club/@thomas/116301990188175266

2010: Let's make GitHub the new SourceForge! The default place for FLOSS code.  

2026: Let's make GitHub the new SourceForge! The awkward outdated cringe code hosting has-been.  

(but this time, ideally, we end up with many federated forges, one could hope!)

#FLOSS

@rysiek I read it as "move everything to Codeberg so we do the same error of centralizing everything, once more"
@bortzmeyer
I remember a story about some Forge, jo, and they wanted to federate.
Even GitLab reopened their ActivityPub issue, but progress is slow and the actual need for ForgeFed-edarion seems to be not so pressing, after all?
@rysiek
@yala @rysiek All my code is at Framagit and by far rhe most common complain I hear from people who wanted to contribute (bug report, pull requests, etc) is "I don't want to create yet another account and to have to use yet another forge".
So, yes, federation is very important.
@bortzmeyer git over email is so underrated...
And yet, it is federated by design, and sometimes even more efficient than some forges...
@yala @rysiek

@x_cli it's not just about git, it's often more about issues and other project management stuff.

@bortzmeyer @yala

@x_cli @bortzmeyer @yala @rysiek counterpoint: the last thing I want is more emails

@cinebox I'm pretty sure the issue is not with the medium and has more to do with the senders and the content xD

Now I would agree that receiving vibe-coded pull requests would certainly feel like receiving spam.

@bortzmeyer @yala @rysiek

The Disconnected Git Workflow

The Disconnected Git Workflow par Ploum - Lionel Dricot.

@ploum @x_cli @bortzmeyer @yala @rysiek And then you try to plug automation to it... And the entire thing falls apart.

This is why most freedesktop.org projects switched away from emails. Patchwork-fdo tried super to provide a consistent view of patch series to review + associated CI results, but emails are too unstructured to work reliably (not including the fact that many email providers tamper with patches).

But worse than this, there cannot be collaboration on a shared global state for the project: no shared list of open issues, no integrated CI,... People just have to read the every email and build a mental image of the whole project. This doesn't scale, and Linux proves it...

I am all for decentralisation and offline operations, but basing it on emails just doesn't work. When all you have is a hammer, everything looks like a nail I guess...

Signed, a Freedesktop.org admin who has been spending 5 years on bringing the i915 driver quality up (https://intel-gfx-ci.01.org/, https://patchwork.freedesktop.org/), then 5 years doing the same in userspace using gitlab. The former is a joke compared to Mesa CI.

Intel GFX CI

@x_cli

I disagree on one point : I am unable to manage git branches with git-sendmail.

@bortzmeyer @yala @rysiek

@tanavit Could you please explain in more details what you mean by "managing git branches"?

@x_cli

Suppose the main manager of a git repository proposes two branches (e.g. main and dev).
If I worked on the dev branch, the patch I will send does not have information about the branch I was working on, nor information about the official commit it applies to.

I may be wrong.

@tanavit @x_cli branch always relate to a commit no need to have branch information , see PostgreSQL project https://wiki.postgresql.org/wiki/Working_with_Git
Working with Git - PostgreSQL wiki

@kryskool

You could have several branches starting from the same commit.

A commit does not identify a branch.

@x_cli

@tanavit @x_cli before apply a patch on local you need to checkout a branch, branch name can be différent in local and remote, i see no problem to apply a patch on the right branch

@tanavit Yesterday, I wasn't able to check this, and a quick search led me to believe I remembered incorrectly but when I run `git format-patch` on a repository, I do get the parent commit-ish in the patch:

```
From 21e80b7abafbe8e31a2e42d01992f073e881cf02 Mon Sep 17 00:00:00 2001
From: Florian Maury <[email protected]>
Date: Mon, 16 Mar 2026 12:41:25 +0000
Subject: [PATCH] chore(deps): bump terraform framework deps

---
go.mod | 18 +++++++++---------
go.sum | 19 +++++++++++++++++++
2 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/go.mod b/go.mod
index 596d211..b689144 100644
--- a/go.mod
+++ b/go.mod
<zip>
```

The "21e80b7abafbe8e31a2e42d01992f073e8" value is the parent commit-ish.
So one can learn which branch this patch was generated on, but I would agree this is not **super** readable.

@x_cli

Thanks for clarification.

But it looks like the name of the local branch in the submitter repo has to be manually added.

@tanavit
Yeah, the name of the local branch is lost. I don't care much about the local branch name in general, but that's a me thing.

@x_cli

In context of collaborative work, having names in common for branches would ease communication.

Actual example : I work on the french translation of a project. It has many branches : main, l10n, and others.

main and l10n are managed at different paces by different people : l10n is quickly updated from submitted patches, main slowly integrates updates from l10n.

They use a single mail adress for submit patches.

Of course, locally I work on my own named branch.

1/2

@x_cli

Then, I pull the l10n branch to my repository, rebase my work on it and send a patch.

I have to manually precise on which branch the patch should apply else the main branch manager refuses it.

It would be easier I publish somewhere my working branch and they pull it, merge it in l10n.

@tanavit
Unless the main ref and the i10n ref all point to the same commit-ish, it would be immediately clear which branch the patchset should be applied on based on the parent commit-ish of the first commit in the patchset, as long as you rebased your branch before creating the patchset.

@x_cli

Thanks for these clarifications.

A lot of things were confused in my mind.

I will be less reluctant to use git-sendmail.

@bortzmeyer @yala @rysiek Worse than having to create an account on some random GitLab instance is being asked to do it again because the one you had was deleted for not being used often enough.
@bortzmeyer
I know of two projects working on a federated git repos solution, one of them is @radicle.
Not tested though.
@yala @rysiek