Who needs Git when you have 1M context windows?

Like the author, I've also found myself wanting to recover an accidentally deleted file. Luckily, some git operations, like `git add` and `git stash`, store files in the repo, even if they're not ultimately committed. Eventually, those files will be garbage collected, but they can stick around for some time.

Git doesn't expose tools to easily search for these files, but I was able to recover the file I deleted by using libgit2 to enumerate all the blobs in the repo, search them for a known string, and dump the contents of matching blobs.

No. Evergreen means CI tests your commit, not relying on individuals to be doing before pushing.

Which is just the PR message if you squash. To be clear, I'm not advocating for bad messages, but I am saying I don't worry about each commit and focus instead on the quality and presentation of the PR.

> The commits are imperfect steps along the way.

The workflow you're describing here is fine for staging or stashing or commits that you don't intend to publish. I'll sometimes commit something unfinished, then make changes and either stash those if it doesn't work out, or commit with --amend (and sometimes --patch) to make a single commit that is clean and coherent. The commits aren't always small, but they're meaningful and it's easier to do this along the way than at the very end when it's not so clear or easy to remember all the details from commits that you made days ago.

> It seems some people treat every commit like it's its own little tidy PR

Pull requests are not always "little". But I'm nitpicking.

It sounds like a big difference between the workflows is that you don't amend or stash anything locally along the way. I guess I find it easier and more valuable to edit and squash changes locally into commits before publishing them. Instead of at the very end as a single pull request. For me, I can easily document my process with good commit messages when everything is fresh in my mind.

The end result is that some commits can be pretty big. Sometimes there is no good opportunity to break them down along the way. That is part of the job. But the end result is that these problems concerning a messy history shouldn't be there. The commits I write should be written with the intent of being meaningful for those who might read it. And it's far easier to do that along the way then at the end when it's being merged. So it's difficult to understand some of the complaints people make when they say it's confusing or messy or whatever.

Even if requirements change along the way while the pull request is open, and more commits are added as a response. I've just never had a situation come up where I'm blaming code or something and looking back at the commit history and struggling to understand what was going on in a way where it would be more clear if it had been squashed. Because the commits are already clean and, again, it's just easier to do this along the way.

But again, I use `git commit --verbose --amend --patch` liberally to publish commits intentionally. And that's why it feels like a bit of busywork and violence when people advocate for squashing those.

Feature branches that have been cleaned up and peer-reviewed/CI-tested, at least in the last few places I worked.

Every so often this still means that devs working on a feature will need to rebase back on the latest version of the shared branch, but if your code is reasonably modular and your project management doesn't have people overlapping too much this shouldn't be terribly painful.