This is just junior level developer thinking. There's so much that this developer doesn't know that they don't know.
Who needs Git when you have 1M context windows?
111–120 of 199 posts
Re: Who needs Git when you have 1M context windows?
#112Most IDEs have Local History built-in to retrieve any version of a file, including untracked deleted files: VSCode Timeline, all JetBrains, Eclipse... Are people coding on notepad ?
in a console talking to your ai friend
Re: Who needs Git when you have 1M context windows?
#113Ok great, now u have retrieved that code that you dont even understand and is completely unmaintainable.
Agreed. Most plausible reason they "can't remember" the good solution is because they were vibe coding and didn't really understand what they were doing. Research mode my ass.
Re: Who needs Git when you have 1M context windows?
#114"Who needs git when [..]" No matter how that sentence ends, I weep for our industry.
Read the article, the author is definitely in favor of using git.
Re: Who needs Git when you have 1M context windows?
#115I 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…
Claude has dropped my dev database about three times at this point. I can totally see how it would drop a prod one if connected to it.
Re: Who needs Git when you have 1M context windows?
#116This article is nonsense.
Re: Who needs Git when you have 1M context windows?
#117Earlier quoted context omitted.
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…
> So maintaining old and new code for X amounts of time? No more than normal? Generally speaking, the author working on the feature is the only one who’s working on the new code, right? The whole team can see it, but generally isn’t using it. > 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 bran…
Medical industry, code that gets shipped has to be documented, even if it's not used. It doesn't mean we can't ship unused code, it just means it's generally a pretty bad idea to do it. Maybe the feature's requirement might change during implementation, or you wanted to do a minor version release but that dead code is for a feature that needs to go into a major version (because of regulations).
> I can’t think of any regulations in any country (and I know of a lot of them) that dictate how you do code changes
https://blog.johner-institute.com/regulatory-affairs/design-...
Re: Who needs Git when you have 1M context windows?
#118If it’s in the context window … it’s sitting around as plain text. I guess asking is easier than scrollback?
Indeed. OP, nothing is "in" an LLM's context window at rest. The old version of your file is just cached in whatever file stores your IDE's chat logs, and this is an expensive way of retrieving what's already on your computer.
Re: Who needs Git when you have 1M context windows?
#119Earlier quoted context omitted.
> 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 t…
> If you want lessons learned put it in a wiki or a special branch.
You already have the information in a commit. Moving that to another database like a wiki or markdown file is work and it is lossy. If you create branches to archive history you end up with branches that stick around indefinitely which I think most would feel is worse.
> Main should be a clear, concise log of changes.
No, that's what a changelog is for.
You can already view a range of commits as one diff in git. You don't need to squash them in the history to do that.
I am beginning to think that the people who advocate for squashing everything have `git commit` bound to ctrl+s and smash that every couple minutes with an auto-generated commit message. The characterization that commits are necessarily messy and need to be squashed as to "minimize the cognitive load" is just not my experience.
Nobody who advocates for squashing even talks about how they reason about squashing the commit messages. Like it doesn't come into their calculation. Why is that? My guess is, they don't write commit messages. And that's a big reason why they think that commits have high "cognitive load".
Some of my commit messages are longer than the code diffs. Other times, the code diffs are substantial and there are is a paragraph or three explaining it in the commit message.
Having to squash commits with paragraphs of commit messages always loses resolution and specificity. It removes context and creates more work for me to try to figure out how to squash it in a way where the messages can be understood with the context removed by the squash. I don't know why you would do that to yourself?
If you have a totally different workflow where your commits are not deliberate, then maybe squashing every merge as a matter of policy makes sense there. But don't advocate that as a general rule for everyone.
Re: Who needs Git when you have 1M context windows?
#120"Who needs git when [..]" No matter how that sentence ends, I weep for our industry.
Reminds me of a colleague back in the day who would force push to main and just leave a "YOLO" comment in the commit.
It's mind-blowing to me that any multi-user git repo is set up to allow pushes to main at all.