@sungo
Hooray for monocultures/centralization! Gotta love putting your trust in a single entity that isn't yourself

@sungo

what's the solution? open source git hosting like gitlab-ce? gitea?

@ben @sungo

The solution is mercurial or Fossil

I understand that Fossil has tickets and pull request

@catonano @sungo

Fossil looks interesting!

I haven't used either fossil or mercurial...

Git is everywhere now though. Makes it hard to use anything else. Is git itself the problem ? Or is it the fact that GitHub has become the defacto host?

@ben @sungo

this question is addressed (to some extent) in the second post of this thread

@catonano @ben And another one is coming :) Trying to respond to everyone now that i'm awake again. (Hitting send just before bed is problematic)

@sungo @catonano

Ahh the barrier to non-experts. I see what you mean. Git certainly is an overly complicated mess.

@ben @sungo

yes I really can relate to that argument

I use git, I use patches sent as attachments on mailing lists, I rebase, I cherrypick

But it's all way too much

@catonano @sungo

There's no right way to do it either. Every project has a different setup and standards for merge/pull requests.

Sidenote: why does GitHub call them pull requests!?!?

@ben @sungo

my main pain point right now is that if I push a rebased branch on a remote repo I don't know how to clean up the mess that will ensue

And I don't want to learn

I'd rather use a backup solution on patch files

@catonano @sungo

Force push :(

@notclacke @sungo @catonano oooooo huh

alrighty then. makes more sense now!

@ben @catonano @sungo

I find a small bit of pleasure in being a contrarian when it comes to software. that said, there is a git front end to hg, the mercurial client, so you can interact with both (somewhat) seamlessly.

@ben @catonano @sungo My understanding is that Fossil can work as a Git server, if anyone insists on using Git.

@alcinnz @catonano @sungo

just compiled fossil. trying it out now :)

@ben @catonano @sungo Not OP, but git itself is the problem - to do things that are a course of normal operation, you have to be an expert in git. That's not feasible for many people - people who should be able to use version control. So, they "need" to use an interface to do things which frankly shouldn't need one.

@emsenn @ben @catonano Yeah, that's what I was ranting about in the rest of the thread :)

@sungo @ben @catonano So I see - I followed from a boost so got shown things out of order. Or read them out of order.

@emsenn @ben @catonano Yup. It's all good. I mostly point at it to save myself from ranting about it again :)

@ben
Mirror all opensource git repos to IPFS then use IPFS as the git URL?
@sungo

@slashzero @sungo

oof that sounds like a lot of work

@ben @sungo and that's why everyone is on GitHub ;)

@slashzero @sungo

Yep... It's easy and everything is already there.

What about gitlab? They're open source!

@ben @sungo Apparently it already works. https://ipfs.io/docs/examples/example-viewer/example#../git/readme.md

@sungo @ben I'll just throw it onto the pile of projects I want to do someday... https://lgbt.io/media/i0hl6HckQdbHti_b0zw

@slashzero @sungo

Ha, yes the ever-lengthening list!

@ben @sungo Imagine if github.com went under, all those golang projects with imports such as "github.com/go-kit/kit/endpoint" would no longer compile.

@slashzero @ben I was just saying that I need to refrain from ranting about that. But it's difficult.

@sungo @slashzero

Lol yeah its hard!

@slashzero @sungo

Those are some *ugly* URLs lol.

I haven't found a compelling use case for ipfs yet...

@ben @sungo yeah, the ugly URLs are why I have "Look into how to deploy a git repo to IPFS under a static human usable name.

OSS projects would likely have to register a domain to point to an IPNS entry.

So let's say I have a domain`slashzero.name` I'd point `git.slashzero.name` to the IPNS entry. then someone would `git clone https://git.slashzero.name/events-rs`

theoretically, we don't even need IPFS to federate projects, just DNS and a HTTPS server.

@slashzero @ben "just"

@sungo @ben It isn't that hard to point a domain to a host. I just pointed git.slashzero.name to github's ip and was able to clone my repo: https://lgbt.io/media/DskPQ3PAoDCdRivjLR0

@slashzero @sungo

And that works with ipfs addresses too?

@notclacke @sungo @slashzero

hmm that could be a nice stopgap between current DNS and ipfs

@notclacke @ben @slashzero Y'all mind untagging me? :)

@ben @sungo With a domain I control, I can point it to somewhere else if my host (in this case github.com) goes away.

That's how Assembly Four was able to fix the censorship of Switter. https://assemblyfour.com/switter/cloudflare-fosta-sesta

Fortunately for them Cloud Flare just deleted their DNS entry to block them.

@sungo @ben Fortunately the web and Internet is built on a decentralized foundation despite the fact we rely on centralized services on top of that foundation.

@slashzero @ben The internet is owned by a few large corporations who can afford to maintain the wires. The web is increasingly centralized too. It's all very depressing.

@sungo @slashzero

unfortunately so :/

@ben @sungo What needs to happen is a federation of git instances like Mastodon and constant domains to those servers.

Smaller projects could use their instance's URL. So https://git.social.coop/slashzero/rs-events could be a gitlab instance for the social.coop community.

Big projects should buy their own domain and CNAME it. https://git.labstack.com/echo would be aliased to https://git.social.coop/labstack/echo

If git.social.coop kills their git hosting, labstack would point the domain at a new instance and forget about it

@slashzero @sungo

i think there would need to be some kind of persistence for those domain records. it's the same problem of having a dependency from github and them being down.

@ben @sungo Hmm? What do you mean by that? DNS is already a distributed system. If my domain server host vanishes, I can move my domain somewhere else.

If my git host vanishes, I can point the domain somewhere else.

For public instances like my git.social.coop example. Small projects make the trade-off of ease of use vs a static project URL. If that instance vanishes, we're still breaking all dependents.

It breaks some projects and not nearly all projects like github.com vanishing.

@slashzero @sungo

that's true. i'm just concerned about renaming and moving things around.

@slashzero @sungo

sounds about right. having control of the domains and dns zones is super important.

@sungo In my opinion, ActivityPub support needs to be implemented in GitLab & Gogs/Gitea to effectively allow for the GitHub workflow in a distributed manner.
Sadly, nor Gitea or Gogs, nor GitLab seem actively interested in the idea, GitLab probably just wants you to use GitLab.com, but then you're just moving the single point of failure under a different umbrella, even if perhaps a more friendly one than GitHub, (since at least GitLab CE is FOSS and they run the company fairly transparently).

@MatejLach I took a look, and ActivityPub would work for this. Pull requests are straightforward: SCM url / branch / revision and some text, with notes replying to it (can add a file/line for specific feedback). Issues are easy. Forking is trivial, though most of it isn't covered by ActivityPub.

@sungo I agree, this is my one big complaint with the #rust community. All of the tools are built with this assumption that github is what you are going to be using, that github is going to be up, and that github will always be around

@sungo Fortunately, the code and history at least won't disappear when Github does unless no one has a local copy... but it's definitely not an optimal situation.