baepaul

fair critique. i'll refrain from it in the future.

but i will say that the point of our post isn't to really sell anyone here or on anything. we kinda know that our product as-is isn't ready to use at real scale (we lack issues, prs, ci, gotta fix a lot of bugs, etc.)

we did just want to sincerely share what we built. and rust is a part of that, we chose it cause we wanted to learn it and we then quickly found out that we really liked it too.

oh wow i have not thought about terminal browsers in a while (i used to use one back in the day in college haha).

yeah, that admittedly is not priority, but thanks for taking the time to check it out.

the hn hug is real indeed, hopefully this link is fine. a bit wordy, but goes into quite a lot of the thinking that went into the design: https://gitdot.io/designs/gitdot-designed-by-developers

it is based off a minimum pixel as of now, apologies.

the overall reason why we didn't ship a mobile site is that code is inherently very hard to read on mobile

and i think to do that properly, you have to design explicitly for it. (and that is not, in fact, something that i do want to vibe code)

thank you both for chiming in.

i will be honest and say that we didn't do our due diligence here (we simply assumed that it would be okay to do so, given the existence of GitHub, GitLab, GitKraken, GitButler, and so forth).

it does look like from digging in: https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw...

that portmanteaus are prohibited by the policy that the Git PLC enforces, which as Jeff notes in his email above, does grant incumbent advantages to grandfathered names (e.g., GitHub, GitLab).

we'll reach out to the conservancy, ask for explicit permission, and if not, rebrand.

thank you!

i'm not aware of the old macOS inspector pattern, but this sounds super interesting and i agree with the critique of inconsistency in github's behavior.

this reminds me a tad of superhuman's right panel too which auto-populates upon writing a time (or typing a name i believe?), which is a feature i do find personally useful as well.

i haven't thought seriously about hovers on nouns quite yet, but this is giving me much to munch on.

thank you sincerely this is dope.

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!

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.

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.

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.

we are well aware and duly noted. thank you for the feedback

yeah this has been pointed out a few times, will revise the copytext later but will keep it up for the duration of the post.

hope our sentiment is clearer in the comments that i've made, i think i've made the mistake of phrasing here with the "anti", i'll revisit it.

edit: dang has removed it, apologies for the confusion i caused, that was my mistake.

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.

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

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.

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

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.

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 :)

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

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.

this is super super cool - awesome to see something technically hard and novel. congrats on the launch!