It stands to reason the OP doesn't understand the code or what he's (probably the LLM) has written if he can't manage to reproduce his own results. We have all been there, but this kind of "try stuff" and "not understand the cause and effect" of your changes is a recipe for long-term disaster. Noticeably also is a lack of desire to understand what the actual change was, and reinforcement of bad development practices.
Who needs Git when you have 1M context windows?
61–70 of 199 posts
Re: Who needs Git when you have 1M context windows?
#62Don'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…
Most of Google's internal development happens on a filesystem that saves absolutely everything in perpetuity. If you save it, the snapshot lives on forever--deleting stuff requires filing a ticket with justification. It is amazingly useful and has saved me many times. Version control is separate, but built on it.
When I eventually move on, I will likely find or implement something similar. It is just so useful.
Re: Who needs Git when you have 1M context windows?
#63If 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
Re: Who needs Git when you have 1M context windows?
#64That’s a lot of words for “I suck at my job”
Re: Who needs Git when you have 1M context windows?
#65Don't take this as career advice! This is an amusing anecdote. But the only lesson to be learned is to commit early, commit often.
hopefully most folks understand that its tongue-in-cheek.
with that said its true that it works =)
Re: Who needs Git when you have 1M context windows?
#66"Who needs git when [..]"
No matter how that sentence ends, I weep for our industry.
Re: Who needs Git when you have 1M context windows?
#67That’s a lot of words for “I suck at my job”
[dead]
Re: Who needs Git when you have 1M context windows?
#68Earlier quoted context omitted.
> Each PR should represent an atomic action against the codebase We can bikeshed about this for days. Not every feature can be made in an atomic way.
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 and we plainly cannot do that even if we wanted to, but that's admittedly a niche case.
Re: Who needs Git when you have 1M context windows?
#69Earlier quoted context omitted.
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…
Most of Google's internal development happens on a filesystem that saves absolutely everything in perpetuity. If you save it, the snapshot lives on forever--deleting stuff requires filing a ticket with justification. It is amazingly useful and has saved me many times. Version control is separate, but built on it. When I eventually move on, I will likely find or implement something similar. It is just so useful.
I used to rely on this on the old DEC systems, when editing and saving foo.dat;3 gave you foo.dat;4. It didn't save everything forever - and you could PURGE older versions - but it saved enough to get me out of trouble many times.
Re: Who needs Git when you have 1M context windows?
#70Earlier quoted context omitted.
> Each PR should represent an atomic action against the codebase We can bikeshed about this for days. Not every feature can be made in an atomic way.
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 keep a history of the failed attemps. Maybe one of them was actually the better solution but you were just short of making it work, or maybe someone in the future will be able to see that method X didn't work and won't have to find out himself.