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

[nine_k]

This is great to know!

SourceHut is new, and likely has a ton of competing priorities.

Also, different groups have different preferred styles of communication. (E.g. chat vs email vs forums is a typical divide.) Different places offer different styles, and this is great, because one size often does not fit all.

That said, most people are conditioned by using GitHub, and this sets their default expectations. Then the network effect kicks in.

[couchand]

I'm not sure we have full data on the question, but by my own experiences the default expectation for most people regarding version control is copy the file and rename it. The default expectation for most people on collaboration tooling is sending an email. If they consider such things at all.

We can easily define a niche within which GitHub-awareness can be presumed but it's certainly not "most people".

[nine_k]

I suspect the majority of people who come to GitHub with intentions other than contributing come either to skim the README for installation instructions, or to complain about a problem. They may not even know about git. This is the wide kind of GitHub-awareness, which still assumes a level of computer literacy above that of most people.

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