Comment

Comment on GitLab abandons federation plans!

NuXCOM_90Percent@lemmy.zip ⁨8⁩ ⁨months⁩ ago

For those who were out of the loop:

What exactly is the idea of federated gitlab? Git is already inherently distributed and automagically mirroring to other remotes is generally like three lines in any CI syntax (and there is probably a precommit hook for it too).

Also: I can see a LOT of security issues with not having a centralized source of truth on what the commit hashes should be and so forth. is fedgit dot zip the source of truth for this app or fedgit dot ml or fedgit dot ca? Theoretically that is where signing comes into play but that gets back to: What advantage does a “fediverse” frontend have?

source

Sort:hotnew top

onlinepersona@programming.dev ⁨8⁩ ⁨months⁩ ago

Git is already inherently distributed and automagically mirroring to other remotes is generally like three lines in any CI syntax (and there is probably a precommit hook for it too).

Git is, but what about everything else? When you clone a project on gitlab or github, does it come with all the issues, discussions, MRs, and so on?

I can see a LOT of security issues with not having a centralized source of truth on what the commit hashes should be and so forth.

That’s what signed commits are for. Also, pull/merge requests and issues are sent to the origin instance, just like in the fediverse. Like now, you made a comment on a post on Fediverse@lemmy.world through your instance lemmy.zip. The same would happen with your comments, pull/merge requests, issue reports, and so on. There’s no need for a “central authority”.

source
- NuXCOM_90Percent@lemmy.zip ⁨8⁩ ⁨months⁩ ago
  Partially addressed in the other branch but:
  
  Issues from people who can’t even be bothered to make a burner account are almost never useful. And issue tracking that is not fed directly to passionate people who care about maintaining a project is worse than worthless.
  
  That’s what signed commits are for
  
  Then it is a good thing I addressed the existence of those. And… those also more or less need a semi-centralized source of truth that is independent of gitlab/hub/whatever.
  
  Also, pull/merge requests and issues are sent to the origin instance, just like in the fediverse
  
  So everything would still happen on the single source of truth for an a project? But you can have an account on whatever service you want?
  
  Homie? You just described oauth.
  
  source
  - onlinepersona@programming.dev ⁨8⁩ ⁨months⁩ ago
    The comparisons you’re making are off base and it feels like you’re mocking something you don’t understand, while doing so with a lot of confidence. I’d suggest you either read an article, watch a video, or read the ActivityPub spec’s intro. It isn’t long and should help you understand the basics. Then you can move on the ForgeFed spec which is the ActivityPub extension for source forges. And you can always ask an LLM to summarise it for you if you really don’t understand.
    
    Anti Commercial-AI license
    
    source
    NuXCOM_90Percent@lemmy.zip ⁨8⁩ ⁨months⁩ ago
    If your goal is to actually make a point or argument: make it. Don’t just tell people to read a manifesto until they agree with you.
    
    source
rglullis@communick.news ⁨8⁩ ⁨months⁩ ago
What advantage does a “fediverse” frontend have?

Github’s dominance comes from the network effects. Everyone’s on github, so if you have your project on a different repo, you won’t get as many visibility. If your project is on gitlab only and someone wants to report a bug, they need to:

Find your instance.

Create an account.

Deal with an unfamiliar interface

Create the ticket

Hope it gets seen.

Potentially forget about it, unless they set up notifications.

A Federated forge solves all of that.

You follow remote projects without having to create an account in the remote instance.

You open an issue on the remote forge without having to open in an account in the remote instance, and you do it from your local server.

If you have a PR ready, the remote instance gets notified.

It makes a lot easier to separate CI/CD from source management.

It makes a lot easier to separate source management from issue tracking.

etc

etc

etc
source
russjr08@bitforged.space ⁨8⁩ ⁨months⁩ ago
I always assumed it was more or less targeting the federation of issues/MRs.

The git side of things is already distributed as you said, but if you decide to host your random project on your own GitLab instance you’ll miss out on people submitting issues/MRs because they won’t want to sign up for an account on your random instance (or sign in with another IdP).

This is where a lot of the reliance of GitHub comes from, in my opinion.

source
- lambalicious@lemmy.sdf.org ⁨8⁩ ⁨months⁩ ago
  People could just submit issues by e-mail, tbh.
  
  I have most of my projects on either notabug or chiselapp (Fosil, not Git) and to this day I get e-mails asking for stuff or notifying about issues, so it’s not like the “social” / “Hub” aspect of “GitHub” is needed.
  
  source
- Fizz@lemmy.nz ⁨8⁩ ⁨months⁩ ago
  Couldnt this be done with email reminders and single sign on?
  
  source
- ademir@lemmy.eco.br ⁨8⁩ ⁨months⁩ ago
  
  This is where a lot of the reliance of GitHub comes from, in my opinion.
  
  100% agree with you here.
  
  source