Live data from Hacker News

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

gitdot.io

21–30 of 322 posts

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

#22
post #9

What's the differentiation against Forgejo going to be?

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-based CI (that's reproducible and locally testible), a super simple and intuitive bug tracker, and just making the site super duper fast and pleasant to use.

that is to say, there is a _lot_ of surface area that a software forge covers and i think there's a lot of room to make things better.

hope that's clear enough, apologies for any ambiguities, we do NOT have all the answers quite yet haha

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

#23

I like the terminal aesthetics but please, for accessibility's sake, make input boxes look more like input boxes and buttons look like buttons.

thank you for the feedback, yeah i've been going and trimming a few places where i think my own tendencies have gone a bit too far.

i will also say on accessibility, i recognize the site is a bit too small font in general — and will fix it soon.

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

#24
Seems interesting an I'll take more of a peek after work, but one thing that stood out to me is the only way back to the home page after navigating to a repo is the back button. Going back to the home page via the back button also doesn't retain that "new" was selected. But I agree with others, I do like the simplicity of the site.

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

#25

I hate that when we scroll through a codebase files, it changes the file we are hovering, I'd rather having to click to see the file

Yes, this particular UX is poor. It's not intuitive that clicking the filename has different behavior from clicking elsewhere in the file's row. Expanding the row inline needs a leading widget. This particular issue is solved in GitHub proper, and derives from the Windows 95 tree view widget [1], which I seem to remember from Windows 3.x but can't find a screenshot. The hover behavior is just not an intuitive or acce…

thank you both for the feedback, i'm revisiting it now and i do see what the both of you are illustrating.

i think i will get rid of the change on hover, it is a distraction and perhaps was just my ambition to show people how fast we load.

edit: fixed

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

#26
post #22
post #9

What's the differentiation against Forgejo going to be?

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 think there's a lot of room to make things better

I think the question is why not try to make the other FOSS forges better instead of reinventing the wheel.

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

#27
post #24

Seems interesting an I'll take more of a peek after work, but one thing that stood out to me is the only way back to the home page after navigating to a repo is the back button. Going back to the home page via the back button also doesn't retain that "new" was selected. But I agree with others, I do like the simplicity of the site.

you can press "h" to go back to homepage :)

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

#28
post #22
post #9

What's the differentiation against Forgejo going to be?

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?

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

#29
It is ... problematic ... to lead with "anti-AI" and then bury terms like "judicious in our use of it" in the fine print.

IMO a team like yours can either:

* Use LLMs, in which case you aren't "anti-AI".

* Not use LLMs currently, but the non-use is not due to following a principle, in which case you aren't "anti-AI".

* Not use LLMs and promise never to do so.

I'm happy you are trying something new. But you hurt yourself by engaging in something very old: disingenuity.

(edits for presentation and grammar)

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

#30
post #24

Seems interesting an I'll take more of a peek after work, but one thing that stood out to me is the only way back to the home page after navigating to a repo is the back button. Going back to the home page via the back button also doesn't retain that "new" was selected. But I agree with others, I do like the simplicity of the site.

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 on github (more likely you find them here on hn or on twitter), so had the restraint of really trying _not_ to make gitdot anything like social media.

but thank you nonetheless for the feedback, i'll revisit it proper and see if i can make this more intuitive.

Post reply on HN