> Who needs git best practices when you have an LLM that remembers everything?
OK, but if you'd used git properly, you wouldn't have had this problem in the first place.
Who needs Git when you have 1M context windows?
121–130 of 199 posts
Re: Who needs Git when you have 1M context windows?
#122Earlier 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.
It is often easier to review commit-by-commit, provided of course that the developer made atomic commits that make sense on their own.
I have literally never met a developer who does this (including myself). 99% of all PRs I have ever created or reviewed consist of a single commit that "does the thing" and N commits that fix issues with/debug failure modes of the initial commit.
Re: Who needs Git when you have 1M context windows?
#123Re: Who needs Git when you have 1M context windows?
#124Earlier 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…
I so miss bazaar's UI around merges/commits/branches. I feel like most of the push for squashing is a result of people trying to work around git's poor UI here.
Re: Who needs Git when you have 1M context windows?
#125"Who needs git when [..]" No matter how that sentence ends, I weep for our industry.
It’s just a joke setup for a funny story
Re: Who needs Git when you have 1M context windows?
#126Earlier quoted context omitted.
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 f…
Commits aren't necessarily messy, but they're also not supposed to be necessarily clean. There's clearly two different work flows here.
It seems some people treat every commit like it's its own little tidy PR, when others do not. For me, a commit is a place to save my WIP when I'm context switching, or to create a save point when I know my code works so that I can revert back to that if something goes awry during refactoring, it's a step on the way to completing my task. The PR is the final product to be reviewed, it's where you get the explanation. The commits are imperfect steps along the way.
For others, every commit is the equivalent of a PR. To me that doesn't make a lot of sense - now the PR isn't an (ideal world) atomic update leading to a single goal, it's a digest of changes, some of which require paragraphs of explanation to understand the reasoning behind. What happens if you realize that your last commit was the incorrect approach? Are you constantly rebasing? Is that the reader's problem? Sure, that happens with PRs as well, but again, that's the difference in process - raising a PR requires a much higher standard of completion than a commit.
Re: Who needs Git when you have 1M context windows?
#127"Who needs git when [..]" No matter how that sentence ends, I weep for our industry.
That's nothing. Compare https://xcancel.com/elonmusk/status/1956583412203958733 : "The phone/computer will just become an edge node for AI, directly rendering pixels with no real operating system or apps in the traditional sense ."
Sounds like the Sun Ray thin client, built by Sun Microsystems in 1999. This was similar to the earlier graphical X terminals, which were reminiscent of mainframe terminals in the 1960s. It's the "wheel of reincarnation".
Re: Who needs Git when you have 1M context windows?
#128"Who needs git when [..]" No matter how that sentence ends, I weep for our industry.
That's nothing. Compare https://xcancel.com/elonmusk/status/1956583412203958733 : "The phone/computer will just become an edge node for AI, directly rendering pixels with no real operating system or apps in the traditional sense ."
What's ridiculous is that second paragraph:
"There isn’t enough bandwidth to transmit video to all devices from the servers and there won’t always be good connectivity, so there still needs to be significant client-side AI compute."
So no real operating system, except an AI which operates the whole computer including all inputs and outputs? I feel like there's a word for that.
Re: Who needs Git when you have 1M context windows?
#129Don'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?)
> (Side ask to people using Jujutsu: isn't it a use case where jujutsu shines?)
Yes! For the case discussed in the article, I actually just wrote a comment yesterday on lobsters about the 'evolog': https://lobste.rs/s/xmlpu8/saving_my_commit_with_jj_evolog#c...
Basically, jj will give you a checkpoint every time you run a jj command, or if you set up file watching, every time a file changes. This means you could recover this sort of thing, assuming you'd either run a commend in the meantime or had turned that on.
Beyond that, it is true in my experience that jj makes it super easy to commit early, commit often, and clean things up afterwards, so even though I was a fan of doing that in git, I do it even more with jj.
Re: Who needs Git when you have 1M context windows?
#130If 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.
I mean there is the chance it's on someone else's computer ^W^W^W^ the cloud, and his provider of choice doesn't offer easy access to deep scrollback ... which means this is only inefficient, not inefficient and pointless.