Live data from Hacker News

Who needs Git when you have 1M context windows?

alexmolas.com

41–50 of 199 posts

Re: Who needs Git when you have 1M context windows?

#41
post #8

Earlier quoted context omitted.

I frequently (basically every conversation) have issues with Claude getting confused about which version of the file it should be building on. Usually what causes it is asking it do something, then manually editing the file to remove or change something myself and giving it back, telling it it should build on top of what I just gave it. It usually takes three or four tries before it will actually use what I just gave…

Your changes aren’t being introduced to its context, that’s why.

The models definitely can get confused if they have multiple copies in their history though, regardless of whether your latest changes are in.

Re: Who needs Git when you have 1M context windows?

#42

1M context is amazing, but even after 100k tokens Gemini 2.5 Pro is usually incapable of consistently reproducing 300 LOC file without changing something in process. And it actually take a lot of effort to make sure it do not touch files it not suppose to.

Exactly, 1M context tokens is marketing, relatively little training was done at that input size.

Re: Who needs Git when you have 1M context windows?

#43
post #10

I cannot wrap my head around the anecdote that opens the article: > Lately I’ve heard a lot of stories of AI accidentally deleting entire codebases or wiping production databases. I simply... I cannot. Someone let a poorly understood AI connected to prod, and it ignored instructions, deleted the database, and tried to hide it. "I will never use this AI again", says this person, but I think he's not going far enough:…

The common story getting shared all over is from a guy named Jason Lemkin. He’s a VC who did a live vibe-coding experiment for a week on Twitter where he wanted to test if he, a non-programmer, could build and run a fake SaaS by himself. The AI agent dropped the “prod” database, but it wasn’t an actual SaaS company or product with customers. The prod database was filled with synthetic data. The entire thing was an ex…

Is there a need for a wiki to collect instances of these stories? Having a place to check what claims are actually being made rather than details drift like an urban legend.

I tried to determine the origin of a story about a family being poisoned by mushrooms that an AI said were edible. The nation seemed to change from time to time and I couldn't pin down the original source. I got the feeling it was an imagined possibility from known instances of AI generated mushroom guides.

There seems to cases of warnings of what could happen that change to "This Totally Happened" behind a paywall followed by a lot of "paywalled-site reported this totally happened".

Re: Who needs Git when you have 1M context windows?

#45
post #38

Don't take this as career advice! This is an amusing anecdote. But the only lesson to be learned is to commit early, commit often.

Commit even as a WIP before cleaning up! I don't really like polluting the commit history like that but with some interactive rebase it can be as if the WIP version never existed. (Side ask to people using Jujutsu: isn't it a use case where jujutsu shines?)

Assuming you squash when you merge the PR (and if you don't, why not?), why even care? Do people actually look through the commit history to review a PR? When I review I'm just looking at the finished product.

Re: Who needs Git when you have 1M context windows?

#46
post #38

Don't take this as career advice! This is an amusing anecdote. But the only lesson to be learned is to commit early, commit often.

Commit even as a WIP before cleaning up! I don't really like polluting the commit history like that but with some interactive rebase it can be as if the WIP version never existed. (Side ask to people using Jujutsu: isn't it a use case where jujutsu shines?)

Git is a distributed version control system. You can do whatever you like locally and it won't "pollute" anything. Just don't merge that stuff into shared branches.

I automatically commit every time my editor (emacs) saves a file and I've been doing this for years (magit-wip). Nobody should be afraid of doing this!

Re: Who needs Git when you have 1M context windows?

#47
post #38

Earlier quoted context omitted.

Commit even as a WIP before cleaning up! I don't really like polluting the commit history like that but with some interactive rebase it can be as if the WIP version never existed. (Side ask to people using Jujutsu: isn't it a use case where jujutsu shines?)

Assuming you squash when you merge the PR (and if you don't, why not?), why even care? Do people actually look through the commit history to review a PR? When I review I'm just looking at the finished product.

Indiscriminate squashing sucks. Atomic commits are great if you want the git history to actually represent a logical changelog for a project, as opposed to a pointless literal keylog of what changes each developer made and when. It will help you if you need to bisect a regression later. It sucks if you bisect and find the change happened in some enormous incohesive commit. Squashing should be done carefully to reform WIP and fix type commits into proper commits that are ready for sharing.

Re: Who needs Git when you have 1M context windows?

#48
post #9

Ok great, now u have retrieved that code that you dont even understand and is completely unmaintainable.

If you're an engineer it can be quite shocking to see how people like the author work. It's much more like science than engineering. A lot of trial and error and swapping things around without fully understanding the implications etc. It doesn't interest me, but it's how all the best results are obtained in ML as far as I can tell.

Re: Who needs Git when you have 1M context windows?

#49

Earlier quoted context omitted.

Assuming you squash when you merge the PR (and if you don't, why not?), why even care? Do people actually look through the commit history to review a PR? When I review I'm just looking at the finished product.

Indiscriminate squashing sucks. Atomic commits are great if you want the git history to actually represent a logical changelog for a project, as opposed to a pointless literal keylog of what changes each developer made and when. It will help you if you need to bisect a regression later. It sucks if you bisect and find the change happened in some enormous incohesive commit. Squashing should be done carefully to reform…

> It sucks if you bisect and find the change happened in some enormous incohesive commit.

But why are any PRs like this? Each PR should represent an atomic action against the codebase - implementing feature 1234, fixing bug 4567. The project's changelog should only be updated at the end of each PR. The fact that I went down the wrong path three times doesn't need to be documented.

Post reply on HN