HN user

shayief

92 karma

Twitter/X: http://x.com/iefserge GitHub: http://github.com/iefserge

Building https://gitpatch.com

Posts5
Comments27
View on HN

This is great, I was looking for something like this, thanks for making this!

I imagine this can very useful for Go-based forges that need syntax highlighting (i.e. Gitea, Forgejo).

I have a strict no-cgo requirement, so I might use it in my project, which is Git+JJ forge https://gitncoffee.com.

If I could only maintain code I wrote, I'd have to work alone.

I don't think that "Code you did not write is code you do not understand" implies that the only way to understand code is to write it. I can read code, run it, debug it and figure out how it works.

It's true that all of that is possible with AI generated code. But the thing is, is it worth for me spending time understanding that PR, when I can make the change or launch my own agent to prompt it myself? At least with my own prompt I know exactly what I want it to be.

this looks very nice.

I see this doesn't use <textarea> or contenteditable, I'm curious how close can it get to native controls or can this replace them? Things like mouse selection and usual hot keys like Cmd+A and maybe other things.

I'm working on a new type of git forge[1], optimized for speed and work with patches.

It goes to extreme lengths to ensure great performance, i.e. rewritten most server-side parts of git from scratch, so there is no "exec"-ing git nor calls to libraries like libgit2. The frontend should also be very fast thanks for HTMX.

[1] https://gitpatch.com

Gitpatch attempts to solve this. Supports versioned patches and patch stacks (aka stacked PRs). Also handles force-pushes in stacks correctly even without Change-IDs using heuristics based on title, author date etc. It should also be unusually fast. Disclosure: I'm the author.

I'm not convinced that review comments as commits make thing easier, but I think storing them in git in some way is a good idea (i.e. git annotations or in commit messages after merge etc)

AI is different 11 months ago

in that every software engineer now depends heavily on copilots

With many engineers using copilots and since LLMs output the most frequent patterns, it's possible that more and more software is going to look the same, which would further reinforce the same patterns.

For example, emdash thing, requires additional prompts and instructions to override it. Doing anything unusual would require more effort.

Jujutsu and Radicle 11 months ago

thanks for checking it out.

yeah, I plan to release it under AGPL at some point when it’s more complete. Currently it still needs more work. But no timeline yet.

Jujutsu and Radicle 11 months ago

Gitpatch author here.

Gitpatch attempts to build a Git hosting with native support for patches and commit-based review system, where each commit is its own patch. It's also smart to handle force pushes and can update or reorder patches as needed.

Codeberg UI appears to be pretty similar to GitHub, so it's great as GitHub alternative. It's powered by Forgejo, fork of Gitea.

Gitpatch is a bit different. It implements a new storage backend and Git library from scratch. It also uses patch-based model for code review vs pull requests, where specially-named branches are used to submit patches and patch stacks.

Fast 12 months ago

ah, interesting. It starts fetching tree items on mousedown (vs onclick) to load them faster, so > starts moving a bit too early.

this is correct, binary dependencies are not supported. The possible way to solve this is to compile non-js code into Asm.js/WASM or directly into js. I think this makes system a bit more stable (null-pointer error in the kernel mode will crash the OS for example) and makes V8 updates much more easier.

It doesn't use threads, but programs are still preemptable. Single event loop uses multiple event queues. Every program owns its own event queue and runs in separate V8 context.

V8 supports script interruption for contexts. Engine puts interrupt guard checks into every function and every loop. So its possible to interrupt context even in a middle of infinite loop.

Yes, system doesn't solve multicore balancing problem for applications automatically. The idea is that every app can use available cores on a machine similar to a fixed size thread pool. So it can manually schedule tasks for available cores.

Whats interesting, that this thread pool could provide transparent access to computing power on other physical machines. So this should be pretty scalable.

GC pauses. Yes, this is a problem, but it shouldn't corrupt any data. I think hardware interfaces should provide some kind of error checking mechanism with the option to retry transmission. Worst case - critical parts implemented in native code.

Another idea how to deal with GC pauses is to reserve one core specifically for V8 concurrent GC tasks for every other core. Additionally this core can take care of all interrupt handlers.