This allows you to use them independently and compose them however you please, which maps well onto the reality of how many projects are organized. Compare this to platforms like GitHub, GitLab, Gitea, and so on, resources like bug trackers and pull requests map 1:1 to a git repository.
I think this is a great leg up on the competition. Having repositories be 1:1 with issue trackers always annoyed me on GitHub and results in hacky workarounds like sending issues between repositories or having one repo act as “the issue tracker repo”.
Happy to see this. I migrated most of my personal projects to sourcehut last year, and despite being overall happy with it, I had the feeling that a lack of search-ability created the impression that there were only a few real users. This will hopefully counter that misconception.
What I find really interesting about this update is the public index. Before there was no way to explore sourcehut. It’s a feature I really enjoyed about github, until they completely crippled it.
Indeed; advanced search and the network effect complement each other as GitHub’s two
killer features. I wrote about how effective these can be in a
comment on Orange Website:
This is excellent. The great thing about Sourcehut is that if you have extra git
remotes, you can keep working like nothing ever happened if the site goes down.
Issues and patches are decentralized over email.
The Project Hub looks like an excellent way to tie together all the separate
Sourcehut services to better compete with other “complete” VCS-based collaboration
suites like GitHub and GitLab. In the future, it would be really cool to expose an
API to allow adding “custom” services that aren’t part of Sourcehut.
It’s good to see Sourcehut focusing on project discovery, since this is the area
where GitHub excels at the most. When I search for a small CLI/TUI utility, I often
run these filters:
filter out weblangs, frontend-oriented languages, and languages with heavy runtimes
(JS, TypeScript, CoffeeScript, Vue, CSS, HTML, Dart, Purescript, Livescript, Elm,
Swift, JVM languages, .NET languages, Vala, QML, etc.). I have several shortcuts
for many combinations of languages so I don’t have to type them out every time.
filter repos below a certain size (a repo above 10mb is probably full of bloat).
If applicable, filter out repos whose last commit was before a certain date.
If applicable, filter by topic
If it concerns a recent technology, I can filter repositories created after a
certain date.
If I want to try a smaller project that isn’t cursed with mainstream success, I
filter repositories below a certain number of stars.
For instance, if I feel like my MPD setup is missing something, I might search:
The result
shows quite a few nice utilities. If I want to go even more minimal, I could filter
out Ruby and even Python projects.
It would be great to have a FOSS implementation of an advanced project search utility
that isn’t limited to (or even part of) any particular hosting provider. Maybe
ActivityPub could help facilitate connecting and indexing project metadata from
different hosting providers.
We are now in the “project hub” for sourcehut. There is already one problem with this UI, which is that there is a “git” link at the top which is a red herring. It takes the viewer to a completely unrelated part of the website.
Now click Sources. That was a happy click, this is where I want to be.
Unfortunately now clicking any of the links such as sourcehut-go takes me out of the project hub.
Contrast this with GitHub, where all of the links at the top are related to the project. Even if I click the organization name, I’m still in the “hub” for the organization, and clicking any of the source repos takes me back to the “hub” for that project.
I do believe there is a way to keep the different parts of sourcehut independent, while making the user experience less confusing for newcomers. But I think you need to think about it from a casual user’s perspective rather than a project maintainer’s perspective.
The links across the top of the page (git, hg, etc) only show for logged-in users, the presumption being that they’re more likely to have been exposed to our documentation and workflow, and understand the purpose of those links.
I mention this in passing at the end of the article, but much of your other complaints should be solved by an upcoming change to the UI for resources on each site - e.g. your git repo - to more clearly link them back to the project they belong to.
u/ddevault I’m not particularly fond of using a circle as sourcehut’s icon, but even ignoring that, the fact that the text is not centered with the circle is triggering the OCD in me really hard. In this image, we can see that top partition is larger than the bottom partition.
hugo serve -w will get it running. The stylesheet is in assets/main.scss, and the HTML is in layouts/partials/nav.html. I can backport the fix to *.sr.ht after that. I spent a few minutes messing with it but I can’t really tell when it’s right.
I think it would be cool if he did some pun because of the word “hut”, maybe just using a caret symbol on top of the circle. I don’t know, just a circle seems bland, personally. And because it is a circle, at a glance it might trick you into reading “Osourcehut”
Welp, this solves my single issue with using SourceHut for everything instead of Github: lack of a central “station” for a project that lets newbies easily find issue trackers and such. It gets slightly old to have to start every project’s README with an index pointing to its various resources.
I might end up running my own sr.ht server someday, but even if I do I’ll gladly pay $50/yr to help keep development rolling.
If it helps any, I would like to suggest to have template projects that represent non-trivial mono-repos
for domain specific examples as:
mobileapp+webapp+desktopapp+distributed-backend
multi-controller-embedded-solution-with-cross-compilation (in several languages)
multi-os-device-driver project
a godot game project for multiple devices
a migration model from multi-repo to a mono-repo
I think setting up project repositories and manage lifecycle of a project (with multiple contributors, pre-releases, releases, dependencies on specific r oss projects, branches, etc) – is becoming a topic on its own.
And I think, these kinds of templates that demonstrate the power of a source management platform, as applied to specific needs, would be of benefit
it’s just a different way of building web applications, with server-rendered templates instead of a single page javascript-powered app that queries an API. both can coexist and learn from each other
I think this is a great leg up on the competition. Having repositories be 1:1 with issue trackers always annoyed me on GitHub and results in hacky workarounds like sending issues between repositories or having one repo act as “the issue tracker repo”.
This is awesome, specially for mirror repositories and stuff like that.
Happy to see this. I migrated most of my personal projects to sourcehut last year, and despite being overall happy with it, I had the feeling that a lack of search-ability created the impression that there were only a few real users. This will hopefully counter that misconception.
What I find really interesting about this update is the public index. Before there was no way to explore sourcehut. It’s a feature I really enjoyed about github, until they completely crippled it.
yeah, it even has a “Featured” column. It is a really clean design.
Ooh, that’s nice! I love it. Add filtering and sorting, and this thing will have GitHub beat by a mile.
Indeed; advanced search and the network effect complement each other as GitHub’s two killer features. I wrote about how effective these can be in a comment on Orange Website:
This is excellent. The great thing about Sourcehut is that if you have extra git remotes, you can keep working like nothing ever happened if the site goes down. Issues and patches are decentralized over email.
The Project Hub looks like an excellent way to tie together all the separate Sourcehut services to better compete with other “complete” VCS-based collaboration suites like GitHub and GitLab. In the future, it would be really cool to expose an API to allow adding “custom” services that aren’t part of Sourcehut.
It’s good to see Sourcehut focusing on project discovery, since this is the area where GitHub excels at the most. When I search for a small CLI/TUI utility, I often run these filters:
filter out weblangs, frontend-oriented languages, and languages with heavy runtimes (JS, TypeScript, CoffeeScript, Vue, CSS, HTML, Dart, Purescript, Livescript, Elm, Swift, JVM languages, .NET languages, Vala, QML, etc.). I have several shortcuts for many combinations of languages so I don’t have to type them out every time.
filter repos below a certain size (a repo above 10mb is probably full of bloat).
If applicable, filter out repos whose last commit was before a certain date.
If applicable, filter by topic
If it concerns a recent technology, I can filter repositories created after a certain date.
If I want to try a smaller project that isn’t cursed with mainstream success, I filter repositories below a certain number of stars.
For instance, if I feel like my MPD setup is missing something, I might search:
The result shows quite a few nice utilities. If I want to go even more minimal, I could filter out Ruby and even Python projects.
It would be great to have a FOSS implementation of an advanced project search utility that isn’t limited to (or even part of) any particular hosting provider. Maybe ActivityPub could help facilitate connecting and indexing project metadata from different hosting providers.
This is progress but does not solve my use case yet. Here’s an example, Drew:
Contrast this with GitHub, where all of the links at the top are related to the project. Even if I click the organization name, I’m still in the “hub” for the organization, and clicking any of the source repos takes me back to the “hub” for that project.
I do believe there is a way to keep the different parts of sourcehut independent, while making the user experience less confusing for newcomers. But I think you need to think about it from a casual user’s perspective rather than a project maintainer’s perspective.
The links across the top of the page (git, hg, etc) only show for logged-in users, the presumption being that they’re more likely to have been exposed to our documentation and workflow, and understand the purpose of those links.
I mention this in passing at the end of the article, but much of your other complaints should be solved by an upcoming change to the UI for resources on each site - e.g. your git repo - to more clearly link them back to the project they belong to.
Thanks for the feedback :)
Does that also explain why https://sr.ht/~sircmpwn/sourcehut/ says “or click “man” along the nav at the top.”, but I don’t see a “man” at the top?
As the main page, https://sourcehut.org/, links to https://sr.ht/~sircmpwn/sourcehut/, you’ll probably get quite a few un-logged-in users seeing this.
That probably does explain it, yes. Thanks for bringing that to my attention, I’ll see what I can do about it.
u/ddevault I’m not particularly fond of using a circle as sourcehut’s icon, but even ignoring that, the fact that the text is not centered with the circle is triggering the OCD in me really hard. In this image, we can see that top partition is larger than the bottom partition.
I have a really bad eye for this… would you mind terribly if I imposed on you for a patch? The code is here:
https://git.sr.ht/~sircmpwn/sourcehut.org
hugo serve -wwill get it running. The stylesheet is inassets/main.scss, and the HTML is inlayouts/partials/nav.html. I can backport the fix to *.sr.ht after that. I spent a few minutes messing with it but I can’t really tell when it’s right.Would you mind if I would also give it a go?
Scyphozoa already sent a patch - and it made it upstream. Maybe you’d like to try it for *.sr.ht, rather than sourcehut.org?
https://git.sr.ht/~sircmpwn/core.sr.ht
See srht/templates/nav.html
Sure. Would you mind if I maybe tried something with the logo?
By all means.
Thanks for replying. I might try, but I have never written a single line of either html or css in my life :(
fwiw, I liked it… encompassing
I think it would be cool if he did some pun because of the word “hut”, maybe just using a caret symbol on top of the circle. I don’t know, just a circle seems bland, personally. And because it is a circle, at a glance it might trick you into reading “Osourcehut”
sôurcehut (:
Welp, this solves my single issue with using SourceHut for everything instead of Github: lack of a central “station” for a project that lets newbies easily find issue trackers and such. It gets slightly old to have to start every project’s README with an index pointing to its various resources.
I might end up running my own sr.ht server someday, but even if I do I’ll gladly pay $50/yr to help keep development rolling.
Not sure if project leaders read this thread.
If it helps any, I would like to suggest to have template projects that represent non-trivial mono-repos for domain specific examples as:
I think setting up project repositories and manage lifecycle of a project (with multiple contributors, pre-releases, releases, dependencies on specific r oss projects, branches, etc) – is becoming a topic on its own.
And I think, these kinds of templates that demonstrate the power of a source management platform, as applied to specific needs, would be of benefit
I’d love to be able to host a mail list that is assigned to a group, rather than a project under my own username.
So far this features has been in the backlog. With this new release, I hope to finally see this feature addressed.
Thanks
I guess I will move all my FOSS to sr.ht.
I really like sourcehut simplicity. But i wonder why wouldn’t they use Javascript in the frontend.
Simplicity.
Agreed
Agreed how can you add interactivity to the site without js Just curious to know
The site’s already interactive. You click on things, and stuff happens. What more would you add?
It depends on the definition of interactivity. HTML has buttons to start with.
Not using JS on the frontend is my #1 favorite feature about sourcehut. It is one or two orders of magnitude faster than GitLab on my old laptop.
There is actually JS is some parts of sourcehut. It’s just optional (as all JS was always meant to be)
I see it’s pretty surprising to see a full fledged application without js where as nowadays js is known to be the universal language of the web
it’s just a different way of building web applications, with server-rendered templates instead of a single page javascript-powered app that queries an API. both can coexist and learn from each other
Agreed Each one has there pros and cons