I would love to know how vibey haxy is. The commits do not contain any info, there is no contribution file, but the author talks quite openly about their local models on YouTube. My first impressions of Haxy were positive, I like how opinionated (is there a better word for that?) it is, but I don't like the lack of information otherwise.
Also, I loved that this project actually is as easy to build as the README describes (though that is at least a bit due to Zig as well, I guess).
That's not a bug, if that's what you're implying. It's inline HTML in Haxy's readme file. Haxy's markdown parser doesn't parse inline HTML at all right now.
It is a bug then. A bug stemming from the lack of implementation, but a bug nonetheless, especially given how the home page is the first thing seen by people potentially interested in the project.
I understand getting turned off by the visual style. Personally I kind of like the quirkiness, at least it’s not the usual LLM-generated pitch page 99% of new projects have these days. But this complaint seems petty.. parsing HTML from a README is hardly the most urgent, interesting or innovative feature of a version control system.
The main thing I really want from a github replacement is local-first issues and pull requests, and haxy promises that. I can forgive a quirky UI in the first release if that’s the price to pay.
I agree about the webui, but I think that’s the least interesting part of haxy. Having local issues and pull requests is great. Also the UI over SSH makes more sense. If a future release reworks the web UI I think it could be an interesting option, and even with the current UI it would work just fine for my own personal projects.
Given how much of the critique around GitHub is directed at their shitty UI (critique I agree with, mind you), I think a presentable home page is the bare minimum for the project to gain any traction among people who aren't necessarily as enthusiastic about technology as Lobsters users.
I also enjoy the quirkiness, but it's going to be off-putting for many since it's the first thing they're going to see when checking out Haxy.
critique around GitHub is directed at their shitty UI
presentable home page
This is the problem. The critique about GitHub UI is not about «presentable», it is about «doesn't work». To move beyond GitHub-quality software, we need to treat «presentable» outright as the warning sign it is.
aren't necessarily as enthusiastic about technology
Also, aren't going to be self-hosting a DVCS server, I guess?
It does seem like the ssh interface may be the inteded homepage. I agree the http one is pretty ugly but it seems... fine? in the ssh interface IMO, but that's subjective ofc.
Whoa do they need a designer, and a web programmer
The events in git seems interesting, I might try to interoperate in my impl. It gives me pause that so far there are zero docs, and the example with the events is not live apparently. I don't understand how authentication for discussions is supposed to work, especially if we want to communicate with federated users
The primary interface is a TUI and the author has built it so that the same TUI code actually can render to terminals and web/html.
I agree that the exact padding/borders/etc needs refinement, but I believe its just a MVP to get something working so that they could build actual innovative part of the project.
I'm only leaving this comment because I feel like you left a patronizing comment about the most superficial/least interesting part of the project.
If the author is reading this, I'd encourage you to look into graceful degredation. Right now, I can't scroll the linked page with javascript disabled.
So one of the issues with Git is that just about any Git related command ends up being very chatty in terms of disk IO, i.e. a git show whatever isn't just a single IO operation, it's a whole bunch of them. When you end up running a forge for many users, this can wreak havoc in terms of performance and outages. Loading non-Git data (e.g. issues) from Git makes this even worse, especially if a project the size of say Kubernetes were to use it (e.g. they have about 50 000 issues in total).
How would Haxy handle that? That's not some sort of "haha gotcha!" question, rather I'm seeing new forges pop up over the last two years or so but few of them seem to actually try to plan ahead/learn from all the scaling horror stories of GitHub, GitLab and others, so I'm curious if Haxy is any different in that regard.
The special haxy/events branch is just an event log. Haxy doesn't need to read it directly every time you browse the issue tracker. It processes the events into materialized views which are properly indexed, so you can browse and search your issues/patches/discussions efficiently.
Ah that makes a lot of sense at least from the perspective of browsing the data. Updating the data is something I could see still being an issue though, at least for projects the size of Kubernetes as you'd constantly have incoming Git traffic (for issues, comments, etc).
So, if I'm understanding this correctly, this is like Fossil, but for Git? It stores everything in the git metadata, not unlike the way that Fossil stores everything in a SQLite file.
As a Fossil user, I want to post the "look at what they need to do to replicate a fraction of our power" meme, but it looks like there is some good work being done here.
kolja | 10 hours ago
I would love to know how vibey haxy is. The commits do not contain any info, there is no contribution file, but the author talks quite openly about their local models on YouTube. My first impressions of Haxy were positive, I like how opinionated (is there a better word for that?) it is, but I don't like the lack of information otherwise.
Also, I loved that this project actually is as easy to build as the README describes (though that is at least a bit due to Zig as well, I guess).
pralkarz | 9 hours ago
I think the concerns are valid given that I see this on the home page: click!
xeubie | 9 hours ago
That's not a bug, if that's what you're implying. It's inline HTML in Haxy's readme file. Haxy's markdown parser doesn't parse inline HTML at all right now.
pralkarz | 9 hours ago
It is a bug then. A bug stemming from the lack of implementation, but a bug nonetheless, especially given how the home page is the first thing seen by people potentially interested in the project.
[OP] krig | 9 hours ago
I understand getting turned off by the visual style. Personally I kind of like the quirkiness, at least it’s not the usual LLM-generated pitch page 99% of new projects have these days. But this complaint seems petty.. parsing HTML from a README is hardly the most urgent, interesting or innovative feature of a version control system.
The main thing I really want from a github replacement is local-first issues and pull requests, and haxy promises that. I can forgive a quirky UI in the first release if that’s the price to pay.
nemith | 6 hours ago
I tried to use Sourcehut but the visual style (esp with whitespace) is a lot for consumers and contributors to my projects to take on.
This whitespace is even worse. Love the backend but this UI is creative and cool, but is a non-starter for me.
[OP] krig | 5 hours ago
I agree about the webui, but I think that’s the least interesting part of haxy. Having local issues and pull requests is great. Also the UI over SSH makes more sense. If a future release reworks the web UI I think it could be an interesting option, and even with the current UI it would work just fine for my own personal projects.
pralkarz | 9 hours ago
Given how much of the critique around GitHub is directed at their shitty UI (critique I agree with, mind you), I think a presentable home page is the bare minimum for the project to gain any traction among people who aren't necessarily as enthusiastic about technology as Lobsters users.
I also enjoy the quirkiness, but it's going to be off-putting for many since it's the first thing they're going to see when checking out Haxy.
[OP] krig | 9 hours ago
Good thing this was posted to lobste.rs then and not to a site for people who aren’t as enthusiastic about technology
k749gtnc9l3w | 8 hours ago
This is the problem. The critique about GitHub UI is not about «presentable», it is about «doesn't work». To move beyond GitHub-quality software, we need to treat «presentable» outright as the warning sign it is.
Also, aren't going to be self-hosting a DVCS server, I guess?
bwbuhse | 6 hours ago
It does seem like the ssh interface may be the inteded homepage. I agree the http one is pretty ugly but it seems... fine? in the ssh interface IMO, but that's subjective ofc.
orib | 4 hours ago
Github's UI appearance-wise varies between acceptable and good. The implementation used to be better, but is now unusable.
morj | 9 hours ago
Whoa do they need a designer, and a web programmer
The events in git seems interesting, I might try to interoperate in my impl. It gives me pause that so far there are zero docs, and the example with the events is not live apparently. I don't understand how authentication for discussions is supposed to work, especially if we want to communicate with federated users
mhanberg | 8 hours ago
The primary interface is a TUI and the author has built it so that the same TUI code actually can render to terminals and web/html.
I agree that the exact padding/borders/etc needs refinement, but I believe its just a MVP to get something working so that they could build actual innovative part of the project.
I'm only leaving this comment because I feel like you left a patronizing comment about the most superficial/least interesting part of the project.
noncrab | 8 hours ago
If the author is reading this, I'd encourage you to look into graceful degredation. Right now, I can't scroll the linked page with javascript disabled.
[OP] krig | 7 hours ago
You can also connect over SSH, and my understanding is that SSH is the primary interface:
ssh try.haxy.net
dsh | 8 hours ago
Bill Hicks and Earth Crisis mentioned in the opening line really got me feeling like I'm 15 again.
yorickpeterse | an hour ago
So one of the issues with Git is that just about any Git related command ends up being very chatty in terms of disk IO, i.e. a
git show whateverisn't just a single IO operation, it's a whole bunch of them. When you end up running a forge for many users, this can wreak havoc in terms of performance and outages. Loading non-Git data (e.g. issues) from Git makes this even worse, especially if a project the size of say Kubernetes were to use it (e.g. they have about 50 000 issues in total).How would Haxy handle that? That's not some sort of "haha gotcha!" question, rather I'm seeing new forges pop up over the last two years or so but few of them seem to actually try to plan ahead/learn from all the scaling horror stories of GitHub, GitLab and others, so I'm curious if Haxy is any different in that regard.
xeubie | an hour ago
The special
haxy/eventsbranch is just an event log. Haxy doesn't need to read it directly every time you browse the issue tracker. It processes the events into materialized views which are properly indexed, so you can browse and search your issues/patches/discussions efficiently.yorickpeterse | an hour ago
Ah that makes a lot of sense at least from the perspective of browsing the data. Updating the data is something I could see still being an issue though, at least for projects the size of Kubernetes as you'd constantly have incoming Git traffic (for issues, comments, etc).
ndegruchy | 3 hours ago
So, if I'm understanding this correctly, this is like Fossil, but for Git? It stores everything in the git metadata, not unlike the way that Fossil stores everything in a SQLite file.
As a Fossil user, I want to post the "look at what they need to do to replicate a fraction of our power" meme, but it looks like there is some good work being done here.