The one true answer

Yes, but why?

"They violently break all the recent frontend best practices. Where is the React or Vie, SPA architecture, tons of JS? There should be a federal law prohibiting making fast and simple UIs so that nobody will have concerns that the UI frameworks war leads us to great future." - viach https://news.ycombinator.com/item?id=20775549

Honestly the UI is confusing and pretty poor. Also looks terrible on Mobile.

Yes but remember, hating on React developers is the what is cool at the moment, thus the project is cool.

I don't have a problem using the UI on mobile. And it looks nice IMO.

And the ability to create a repo on their site by just pushing to a remote with the right name[1] has really made it easier for me to use their service. What do you find confusing and poor about the UI? I find it straightforward and efficient.

[1](https://geoff.tuxpup.com/posts/cool_sr_ht_feature/)

Maybe I was being too critical - it is actually quite nice on mobile.

I do use the find-file feature on Github a lot, as well as the quick file editor. Both are missing here, but I kind of see that at least the file editor is not well suited to the projects ethos.

Because it’s cool! Also it’s extremely open source, has a cool tech blog, and feels like it has a lot of momentum

For starters, it's not owned by a gigagroup

Instead it's owned by an abrasive difficult to deal with developer who will argue "you're just doing it wrong" with paying customers. Clearly things aren't exactly roses and sunshine here either.

Idk, I don't have the source for the conversation, but I suspect "direct" is being misinterpreted as "rude".

Using git and mercurial for large binary file storage is, 100%, wrong. Why? They're not designed for it, so they handle it really poorly. Hacks like Git LFS and annex were made for a reason.

From sourcehuts perspective, they need to serve all their customers, and an extreme performance outlier for a still small platform could degrade the experience for others by becoming a significant part of the server load. Thus, it's fair to say no.

Just like Github did back in the day to CocoaPod: https://news.ycombinator.com/item?id=11245652. They also got very unhappy.

That sounds like a positive to me.

Example?

e.g. https://lobste.rs/s/j1gl4t/sourcehut_prohibits_repos_with_la...

Both the original story as well as the comments regarding Andrew's usage for Zig.

That doesn't sound abrasive at all to me. It's just a normal technical disagreement. What am I missing?

You don't think it's strange for a service provider to tell people that "mercurial isn't suitable for this" (even though it clearly works, and has been working for many years) and "you're writing your program wrong"?

It's fine to not support certain use cases because it's too much effort or otherwise too expensive. It's not fine to, as a service provider, tell people that their programs are (and I quote) "wrong".

If you're okay with that then that's your choice, but for me it really turned me off sourcehut.

> You don't think it's strange for a service provider to tell people that "mercurial isn't suitable for this" (even though it clearly works, and has been working for many years) and "you're writing your program wrong"?

No, not really, if done politely. Which seems to be the case here.

It also might "work" to use a large crystal vase as a hammer, but it's still "doing it wrong".

If anything, I'd fault sr.ht for having too vague usage policies and then telling users they are in violation of said policies. That's not good. But they are in alpha, so hopefully it's something that'll improve.

No, because mercurial really isn't suitable for this. Nor is Git for that matter.

Similar thing happened on Github with CocoaPods: https://news.ycombinator.com/item?id=11245652.

It works, so it's suitable.

If I duct tape you to a car seat it will work just like a seat belt.

Just because something works doesn't mean it is a suitable implementation or a sensible decision.

No. That's one reason we have separate words for things that work and things that are suitable.

It doesn't (and didn't at the time) sound abrasive to me, either.

Perhaps a relevant comparison here is Pinboard.

It's a paid subscription website and has done very well as a one-man-army project. Its success hasn't compromised its virtues of being lightweight and no-nonsense (unlike Delicious).

If SourceHut could do the same for Git that would be great.

> If SourceHut could do the same for Git that would be great.

It already does. Other than some (minor) missing features that are in active development, what else do you need?

It's a 'public alpha'. Personally I won't be signing up until it's describing itself as stable.

You can sign-in for free while it is alpha and try it. Everything works very well except the account data export that is not still enabled. I have found it very practical and fast, much better than the typical github+travis combination.

Their description of "alpha" is more stable than many services that describe themselves as stable, IMO:

https://sourcehut.org/alpha-details/