[martingxx]

I just interpret this whole thing as "developer realises their preferred set of trade-offs matches host A more than host B, so they are switching hosts". This happens fairly frequently in various directions for many different reasons.

Slightly off topic, but related: I wish we could focus less on which git host is "best" and more on figuring out workable interoperability between them. Sadly, it seems less of a technical challenge and more a question of motive.

[nine_k]

But it's not about a git host. It's about a discussion / issues / code review host.

All it takes to host git proper is a network-accessible machine with git and ssh. It's the trivial part.

Making it convenient for you to communicate with other varied humans contributing to, or otherwise interested in the code, is the key differentiator. And apparently this is not the part SourceHut prioritizes. No wonder, because it's the hardest part.

[couchand]

> Making it convenient for you to communicate with other varied humans contributing to, or otherwise interested in the code, is the key differentiator. And apparently this is not the part SourceHut prioritizes. No wonder, because it's the hardest part.

Just because you don't seem to understand or agree with another person's priorities doesn't mean that they don't have them. By my reading, contributors to SourceHut absolutely do prioritize tools that humans use to communicate, and in particular ones that have been demonstrated to support complex and nuanced technical discussions.

[taion]

It's also not entirely a technical issue, anyway. In a vacuum the Sourcehut UX might be fine, but if people are used to GitHub-style UX, then they will have a hard time with Sourcehut and end up doing the wrong thing, like emailing the maintainer directly rather than using the mailing lists – through no fault of the mailing lists themselves!

[busterarm]

Sourcehut is really targeting users who want an email-centric workflow, which it excels at. It's not trying to be(at) GitHub.

You want it to be something that it isn't.

[martingxx]

I agree about the discussion / issues aspects. I suspect doing that interoperably would be hard or impossible because of the vastly different feature sets on different hosts.

All I am looking for is a few interoperability features for the repositories themselves. In fact, if I were to describe the most important single feature, it would be something like this:

I am able do some work in my repo hosted on host A, which was originally cloned from a repo on host B, and offer it back to the author on host B to merge if they wish. I'd like to be able to do this by notifying them (in a way integrated into my workflow) with the same kind of information that `git request-pull` generates. Importantly I would not need an account on host B for this. Possibly this might need some one-off setup on the original authors side, perhaps adding my repo as an remote.

The use cases I have in mind here are mostly occasional contributions or minor changes. I don't think this would work well for people who are frequent major contributors - they would really need the discussion / issues aspects to collaborate effectively.