Live data from Hacker News

Who needs Git when you have 1M context windows?

alexmolas.com

81–90 of 199 posts

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

#81
post #56

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.

I think maybe one other lesson, although I certainly agree with yours, and with the other commenters who talk about the unreliability of this particular method? This feels like an argument for using an editor that autosaves history. "Disk is cheap," as they say -- so what if your undo buffer for any given file goes back seven days, or a month? With a good interface to browse through the history? I'm sure there's an e…

Jetbrain's local history has saved my bacon several times. Its a good use of all that unused disc space.

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

#82
I had a similar anecdotal experience a few weeks ago.

I was working on a blog entry in a VS Code window and I hadn't yet saved it to disk. Then I accidentally hit the close-window keyboard shortcut... and it was gone. The "open last closed window" feature didn't recover it.

On a hunch, I ran some rg searches in my VS Code Library feature on fragments of text I could remember from what I had written... and it turned out there was a VS Code Copilot log file with a bunch of JSON in it that recorded a recent transaction with their backend - and contained the text I had lost.

I grabbed a copy of that file and ran it through my (vibe-coded) JSON string extraction tool https://tools.simonwillison.net/json-string-extractor to get my work back.

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

#83
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.

It is often easier to review commit-by-commit, provided of course that the developer made atomic commits that make sense on their own.

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

#84

If you sent the python file to Gemini, wouldn't it be in your database for the chat? I don't think relying on uncertain context window is even needed here! A big goal while developing Yggdrasil was for it to act as long term documentation for scenarios like you describe! As LLM use increases, I imagine each dev generating so much more data than before, our plans, considerations, knowledge have almost been moved parti…

I confused it with this for a min, which I have played with: https://github.com/yggdrasil-network/yggdrasil-go

Browsing that repo is a bit trippy after being used to my own all this time haha.

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

#86
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?)

I assume Jujutsu only commits the file when you use one of the jj commands. I don't think it keeps a daemon running and checking for changes in the files.

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

#88

Earlier quoted context omitted.

This simply isn’t true unless you have to put everything in one commit? To be honest, I usually get this with people who have never realized that you can merge dead code (code that is never called). You can basically merge an entire feature this way, with the last PR “turning it on” or adding a feature flag — optionally removing the old code at this point as well.

So maintaining old and new code for X amounts of time? That sounds acceptable in some limited cases, and terrible in many others. If the code is being changed for another reason, or the new feature needs to update code used in many places, etc. It can be much more practical to just have a long-lived branch, merge changes from upstream yourself, and merge when it's ready. My industry is also fairly strictly regulated…

Our regulatory compliance regime hates it when we run non-main branches in production and specifically requires us to use feature flagging in order to delay rollouts of new code paths to higher-risk markets. YMMV.

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

#89

Earlier quoted context omitted.

That's true, some are big and messy, or the change has to be created across a couple of PRs, but I don't think that the answer to "some PRs are messy" is "let's include all the mess". I don't think the job is made easier by having to dig through a half dozen messy commits to find where the bug is as opposed to one or two large ones.

> I don't think that the answer to "some PRs are messy" is "let's include all the mess" Hey look at us, two alike thinking people! I never said "let's include all the mess". Looking at the other extreme someone in this thread said they didn't want other people to see the 3 attempts it took to get it right. Sure if it's just a mess (or, since this is 2025, ai slop) squash it away. But in some situations you want to ke…

I can see the intent, but how often do people look through commit history to learn anything beside "when did this break and why"? If you want lessons learned put it in a wiki or a special branch.

Main should be a clear, concise log of changes. It's already hard enough to parse code and it's made even harder by then parsing versions throughout the code's history, we should try to minimize the cognitive load required to track the number of times something is added and then immediately removed because there's going to be enough of that already in the finished merges.

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

#90

A fun anecdote, and I assume it's tongue in cheek, although you never know these days, but is the LLM guaranteed to give you back an uncorrupted version of the file? A lossy version control system seems to me to be only marginally better than having no VCS at all.

When I used toolcalls with uuids in the name, tiny models like quantized qwen3-0.6B would occasionally get some digits in the UUID wrong. Rarely, but often enough to notice even without automation. Larger models are much better, but give them enough text and they also make mistakes transcribing it
Post reply on HN