Live data from Hacker News

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

gitdot.io

11–20 of 322 posts

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

#11
I think you're in an interesting space where there's a real opportunity to create something fresh. When people are actively looking for alternatives it will be easier to break out of the established norms.

What does anti-AI mean? Don't really see anything about it in the design doc except "no AI copilot".

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

#12

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 accessible default. I can't imagine someone being able to use this if they have a hard time clicking without moving the mouse. It also wastes resources fetching file/directory contents while the user is moving the cursor to a predetermined file they presumably wish to open.

[1]: https://learn.microsoft.com/en-us/windows/win32/winauto/syst...

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

#13

Why does it have to be a website? Why merely "CLI-inspired" and not actually CLIs?

Removes a barrier of entry if you can look at it from a browser instead of installing a CLI/TUI.

Don't try to make me install a random program if I can view it in my sandboxed browser safely.

Also, browsers have greasemonkey to help me personalize websites easily. TUIs don't.

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

#14

Why does it have to be a website? Why merely "CLI-inspired" and not actually CLIs?

hrm. so i guess if the question is why not just make a software forge that is _only_ based in the CLI, the answer i think is convenience.

it's very convenient to be sent a link (or find it on hacker news) and to be able to click around files, read the README, understand what a repository is about without having to clone it and open locally. plus -- if you only need a barebones git server with no web UI, git provides this by default.

if the question is, will you build a CLI / what will be in it? the answer is yes, we do have a barebones CLI for auth as of now, do envision things like managing issues / PRs from the CLI, but want to make sure that strike the right balance there.

i think TUIs can be deceptively hard to build well, and admittedly, it hasn't been a priority for us quite yet.

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

#15
The minimal look feels very refreshing, and yet it's not disorienting like many minimal web git UIs are in my experience; I actually feel like I know how to navigate this thing. Site feels very snappy too, especially with those instantly loading file previews when you hover. Congrats!

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

#16

> 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…

That's not really anti-AI. Anti-AI would mean avoiding it as a value regardless of practicality.

That sounds more like anti-enshittification.

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

#17

> 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…

yeah thanks for digging in, this was a bit ambiguous.

so take this to mean - 1) no AI copilot in the app and 2) no training on your data nor selling of it.

our take on AI is that we should focus on building tools that help address its limitations; one of the things we're particularly keen on is building stacked diffs into reviews as a primitive, so it's easier to review a large AI-generated (or assisted) PR. (e.g., diff 1 for API changes, diff 2 for backend wireup, diff 3 for front-end changes)

i think to do that, we're going to try and hook into the subscriptions that people already have and are paying for: Claude, Codex, rather than package our own, but some of that is a bit hacky to do.

hope that's clearer and thank you for asking

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

#18

The minimal look feels very refreshing, and yet it's not disorienting like many minimal web git UIs are in my experience; I actually feel like I know how to navigate this thing. Site feels very snappy too, especially with those instantly loading file previews when you hover. Congrats!

thank you! of all things in this launch, i was the most anxious about the design as it is admittedly the most different.

glad to hear the positive feedback :)

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

#19
post #11

I think you're in an interesting space where there's a real opportunity to create something fresh. When people are actively looking for alternatives it will be easier to break out of the established norms. What does anti-AI mean? Don't really see anything about it in the design doc except "no AI copilot".

thank you kiro! (i feel you may be slightly miffed about the AWS IDE taking your name haha)

i replied in a separate comment: https://news.ycombinator.com/item?id=48452052 but to reiterate: 1) no AI copilot and 2) no training or selling of your data.

but overall, the general ethos is to focus on the problems that AI is introducing as of now and how we can help solve them, rather than just build AI features with abandon assuming that they're good.

some stuff that we do know about: the influx of slop PRs / slop issues on popular repositories, losing agency our own of code as we AI generates more, and privacy/sovereignty of code.

i've talked a bit about stacked diffs which we do see as one concrete stab in that direction, but a lot here is to be admittedly sketched out.

Post reply on HN