21–30 of 35 posts
Earlier quoted context omitted.
Easy installation instructions says no.
https://man.sr.ht/installation.md
Earlier quoted context omitted.
https://man.sr.ht/installation.md
These are probably the opposite of what most people would call "Easy installation instructions" if you compare it to Gitlab's Omnibus package for example. They are well written and probably complete but not what people would call easy.
These ideological decisions don't sound very pragmatic. There's a lot of open-source prior art in this space (OpenGrok, Kythe, SourceGraph) which provide support for most large languages and have annotation output formats that are broadly similar to this JSON file, and you could still support users having indexers for small languages running as part of CI. > There does not exist any widely available standalone C pars…
Github also recently open-sourced their Haskell-based Semantic, which annotates and cross-references a whole bunch of languages (all the languages any of our clients use), and is built on tree-sitter, so there's, like, several levels of prior art available here.
If I wanted good code reviewing with Haskell, I figure it would be best to translate HIE files (https://www.haskell.org/ghc/blog/20190626-HIEFiles.html) to LSIF (https://github.com/mpickering/hie-lsif), which is supported in VSCode. Because of the limitations of only parsing, GitHub alone will not be as powerful. If I then just make an LSIF to SourceHut converter, SourceHut will have better annotations than GitHub...
Conceivably someone could write an offline annotation viewer/editor as well? I would love for something like that to catch on.
Imagine Emacs and Pycharm plugins for viewing and editing these annotations, for example.
Wow, this is great! Conceivably someone could write an offline annotation viewer/editor as well? I would love for something like that to catch on. Imagine Emacs and Pycharm plugins for viewing and editing these annotations, for example.
These ideological decisions don't sound very pragmatic. There's a lot of open-source prior art in this space (OpenGrok, Kythe, SourceGraph) which provide support for most large languages and have annotation output formats that are broadly similar to this JSON file, and you could still support users having indexers for small languages running as part of CI. > There does not exist any widely available standalone C pars…
Github also recently open-sourced their Haskell-based Semantic, which annotates and cross-references a whole bunch of languages (all the languages any of our clients use), and is built on tree-sitter, so there's, like, several levels of prior art available here.
But, plugging Semantic into SourceHut should be totally possible with some mild massaging of the output JSON.
So excited to use this once my requirements are implemented (mostly just LFS, and to a lesser extent Merge(|Pull) Requests) . Admittedly I don't need it, I just really appreciate the simplistic UI and straight forward pricing model.
LFS support is something I'd like to do, but It's Complicated(TM). Main challenges include finding a good place with ample bandwidth and storage, figuring out where/how to take backups of it, and measuring bandwidth and storage usage to integrate with billing. Not a priority right now, but may land between the beta and stable periods. As for merge requests, don't hold your breath. SourceHut embraces the email-based m…
are they offering HTTPS yet - i would like to move away from GitHub if possible
I assume you're the same person I've been talking to on Lobsters. Clarification: they're talking about git push over https, which is deliberately unsupported in favor of the more secure SSH push option. git.sr.ht doesn't even have access to your password, so if the server is compromised then the attacker can't dump password hashes.
Earlier quoted context omitted.
LFS support is something I'd like to do, but It's Complicated(TM). Main challenges include finding a good place with ample bandwidth and storage, figuring out where/how to take backups of it, and measuring bandwidth and storage usage to integrate with billing. Not a priority right now, but may land between the beta and stable periods. As for merge requests, don't hold your breath. SourceHut embraces the email-based m…
My issue with emails is that the user experience isn't as good and while it can be a worthwhile tradeoff for the points you mention, most of them are irrelevant in an enterprise setting (think using an internal SourceHut server instead of self-hosted GitLab or Bitbucket Server) so the UX benefit would be very much welcome.
However, I don't focus on the enterprise crowd, you're right about that.
Earlier quoted context omitted.
My issue with emails is that the user experience isn't as good and while it can be a worthwhile tradeoff for the points you mention, most of them are irrelevant in an enterprise setting (think using an internal SourceHut server instead of self-hosted GitLab or Bitbucket Server) so the UX benefit would be very much welcome.
I honestly disagree that the user experience isn't as good, and I don't think people have enough faith to try it out for a while. I've spent thousands of hours in many workflows and I still find email to be the easiest and most efficient way of doing it. However, I don't focus on the enterprise crowd, you're right about that.
I'm not necessarily saying it's the right choice for Source Hut, but I think it's part of the reason why Github is quite successful in the open source community.