Live data from Hacker News

Show HN: Gitdot – A better GitHub. Open-source, written in Rust

gitdot.io

41–50 of 322 posts

Re: Show HN: Gitdot – A better GitHub. Open-source, written in Rust

#42
post #28
post #22

Earlier quoted context omitted.

forgejo is a pretty great piece of software. a lot of this we've really come to know as we dug into both it, gittea, gitlab, and all of their internals. i think the short answer as to a differentiator is design. our goal's to just build the best product possible, one that we'd love to use and one that we hope developers do too. some of the stuff we've been thinking about include: stacked diffs as PR primitive, a Nix-…

I'm a bit confused, aren't the Forgejo people trying to build the "best product possible", too? And there's more of them, and they have funding, and… between 2 good forges or 1 great one, I rather have 1 great one… I guess you're not interested in joining them because it's not Rust?

thank you both for asking.

i think the honest answer here is autonomy. the freedom to choose our own tech stack, our own product priorities, and our own design.

i'll also admit that i don't know forgejo's own priorities as well as i do our own, and that is negligence that we're due to correct. maybe they are perfectly aligned and it does make sense for us to join forces.

but just as with any FOSS project, they have the freedom to choose what they work on as do we, and i intend on respecting that.

Re: Show HN: Gitdot – A better GitHub. Open-source, written in Rust

#43

> 5. What features will gitdot not have? > AI. > We view AI as an implementation detail — and do not think that using it is necessarily good. > In fact, we think it makes many products worse by acting as a bandaid for poor design. > That isn’t to say we are blind to it, but that we will be judicious in our use of it instead. Not sure I follow. What feature are the developers referring to? I understand that AI will po…

I'm honestly lost for words over how you can write something like this while the web app's source code is clearly heavily integrated with Claude Code.

https://gitdot.io/bkdevs/gitdot/files

Re: Show HN: Gitdot – A better GitHub. Open-source, written in Rust

#44
post #41

Maybe it’s the HN effect but /files takes a while to load. Personally while I appreciate something not being AI slop, writing something in Rust has no meaning to me.

yeah this is because we're currently (very temporarily) hosting things in NFS and git stat operations are very slow since they assume a fast file FS. we'll fix that in a few.

and yeahhhh, i do try to be very non-marketing in all that i say, but something about the title made me a bit ambitious, apologies.

Re: Show HN: Gitdot – A better GitHub. Open-source, written in Rust

#45
post #39
post #30

Earlier quoted context omitted.

this hn thread is interesting as it feels like i'm getting to revisit a lot of decisions i've made in the design haha. i debated this for a while too, some of my thinking for how it is is that i wanted the focus of a repository page to be _the repository_. so as much as we can, trim things that might detract. it was also done with the intention that it's actually pretty rare for a user to find or explore repositories…

I’m not sure I agree with all of your takes either. For example, I’m not anti-AI for coding, so that immediately made me click away. I’m glad I read the comments though because I think the take of “not using your code to train AI” makes a lot more sense. But, I wanted to say thanks for posting this and being really open in the comments. It’s hard to get so much feedback so quickly. It’s a firehouse of criticism that’…

thank you mbreese, i know folks can be mean and i also recognize where they're coming from (we are certainly far from perfect), but this comment is nice to read.

thank you for the empathy.

Re: Show HN: Gitdot – A better GitHub. Open-source, written in Rust

#47
A lot of fuss that needs to be chiseled out first. There's an idiom that is followed a bit too black and white, but the grey is grey.

No loading animation, but my screen jitters while loading in stuff. My internet speed is fine, so it's a performance/bug issue.

I also did not initially understand the UI, but that'll come as I use it more

Re: Show HN: Gitdot – A better GitHub. Open-source, written in Rust

#48

A lot of fuss that needs to be chiseled out first. There's an idiom that is followed a bit too black and white, but the grey is grey. No loading animation, but my screen jitters while loading in stuff. My internet speed is fine, so it's a performance/bug issue. I also did not initially understand the UI, but that'll come as I use it more

yeah the site isn't perfect.

my fixation here is to make everything load instant, but that is dependent on server latencies, which right now is admittedly slow as we only have one server in the US.

but thank you for giving it a shot nonetheless!

Re: Show HN: Gitdot – A better GitHub. Open-source, written in Rust

#49
Interesting stuff! I really like the design philosophy you're applying here, where the browser/web behaviour is actually part of the UX. Pretty rare for web application nowadays!

If I could make one suggestion, I really like the old MacOS "inspector" pattern. Basically a consistent way to get meta-information about any "thing" the user chooses to inspect. Your right sidebar is going towards that, but it would need some work to make it more consistent between views.

GitHub's UI has these weird meta-states/restrictions that are so badly explained in the UI they feel like bugs. Each line gets a [...] menu in github which lets you see the blame/spawn a issue linking to it/get a permalink/etc. It's a totally different UI in the diff view, and then totally different again if you're looking at a comment referencing a line in a diff AND different if it's referencing a permalink to a line in a file, even if it's the same code that would be in that diff!

I want the UI to have obvious "nouns". If the UI is showing me a line of code, even if it's in a diff view, let me "inspect" it and get the exact same meta-info + tools I get for lines of code anywhere. It's "a line", not a weird meta state of "a line, but you're in the comment of a PR linking to this line".

Same concept applies to comments/commits/authors/etc. If the UI shows me a username, I should be able to pull up a "who is that again" inspector. Going into github's commit view, clicking on a name... and being sent to a filtered list of that person's commits makes zero sense to me because this is the ONLY place where that happens. That behaviour should be a "recent commits" button inside some "user inspector".

Post reply on HN