2010: Let's make GitHub the new SourceForge!

[x_cli@infosec.exchange]

@lienrag
Here is a tutorial. I used it in a previous job and it was great and way better than Gitlab at that time https://git-send-email.io/#step-1

[artlog@agora.l0g.eu]

@lienrag @x_cli

A debian way of life

[rysiek@mstdn.social]

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

@bortzmeyer @yala

[cinebox@masto.hackers.town]

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

[technomancy@hey.hagelb.org]

@rysiek it's for real https://sou.rceforge.net/github/copilot-cli

[x_cli@infosec.exchange]

@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

[bmarinov@hachyderm.io]

@yala
I wanted to contribute to #garage S3 and they self host a forgejoe. It was a bit annoying having to create an account. It probably cost me two days before I opened an issue and my PR. It is just friction we need to solve.
@bortzmeyer @rysiek

Wrt codeberg and forgejoe, I'm wondering how actual development and independent feature contributions are compared to gitea.

[ploum@mamot.fr]

@x_cli @bortzmeyer @yala @rysiek : and it works offline !

The Disconnected Git Workflow

The Disconnected Git Workflow par Ploum - Lionel Dricot.

(ploum.net)

[tanavit@toot.aquilenet.fr]

@x_cli

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

@bortzmeyer @yala @rysiek

[x_cli@infosec.exchange]

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

[mupuf@social.treehouse.systems]

@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.

[tanavit@toot.aquilenet.fr]

@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.

[changaco@diaspodon.fr]

@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.

[x_cli@infosec.exchange]

@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?

[tanavit@toot.aquilenet.fr]

@x_cli

I agree.

[daks@mamot.fr]

@bortzmeyer
I know of two projects working on a federated git repos solution, one of them is @radicle.
Not tested though.
@yala @rysiek