Hacker News Reader

Comment by SBArbeit | Hacker News Reader

A big design driver for Grace is eliminating fear around using version control.

Merge conflicts are one of the big places where fear can happen, even if it's subtle; you think you're all done with your work and then... ugh, what happened? are my changes stepping on the other changes? are they stepping on mine? do I have to retest? etc.

Having an event-driven, automatic AI review of a conflict is just something that makes sense today. I don't just want to tell you there's a conflict, I want to tell you there's a conflict and give you a solution to it that you can accept with one click if it looks good. Grace will even be able to run CI/CD pipelines against that proposed resolution before it tells you about it to help you make the decision.

View on HN

I'm not sure how that makes sense today, to me it's more of a novel idea than a solution to a problem. I use AI every day in my workflow and I honestly don't believe it's capable of reliably solving merge conflicts. GPT-4 can write a really nice method but can't integrate it into my code-base. If half of the proposed solutions are incorrect, I need to scrutinize all proposed solutions equally. Would I rather review likely inaccurate conflict resolutions, only to solve it myself afterwards, or resolve it myself from the get-go in a way that I know makes sense? Do I want to give my teammates the ability to click a button and introduce subtle merge bugs?

Don't get hung up on what GPT-4 can do. That's irrelevant. Even Sam Altman calls GPT-4 "mildly embarrassing".

"Don't skate to where the puck is, skate to where the puck is going." In 2028, for instance, will GPT-7 (or whatever) be able to handle solving a merge conflict? I expect it will.

Ok, so are you advertising your product using features it doesn’t yet have? Not cool.

It's totally cool. It's not a product yet, it's a one-person project so far. I'm not asking anyone for any money. I expect one day that it will be a product.

It's still an alpha (see the highlighted note towards the top of the readme). There are features I intend to ship in 1.0 that aren't even started.

And even if all goes as well as possible, it won't ship 1.0 until 2026 at the earliest, which means early adopters, and mass adoption not until 2027 or 2028.

If you're going after something as big as Git, it takes time. It would be irresponsible to not think about where computing will be in a few years vs. today as I work on it.

Linus wrote git over a weekend...

[Edit: and that's why it's so good! Because it's so damn simple!]

Reply on news.ycombinator.com