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

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 It could be easily added to the cover letter, but AFAIK, you are correct that a "patch" (format-patch) won't contain that info by default.
git-request-pull is probably more suited for this?

@x_cli

I agree.