91–100 of 199 posts
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 o…
Earlier 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.
We can agree that we don't need those additional steps once the PR is merged, though, right?
Ok great, now u have retrieved that code that you dont even understand and is completely unmaintainable.
If you're an engineer it can be quite shocking to see how people like the author work. It's much more like science than engineering. A lot of trial and error and swapping things around without fully understanding the implications etc. It doesn't interest me, but it's how all the best results are obtained in ML as far as I can tell.
Guessing without understanding is extremely unlikely to produce the best results in a repeatable manner. It's surprising to me when companies don't know that. For that reason, I generally want to work with experts that understand what they're doing (otherwise is probably a waste of time).
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.
Earlier quoted context omitted.
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…
Alternative to squashing is not a beautiful atomic commits. It is series of commits where commit #5 fixes commit #2 and intruduces bug to be fixed on commit #7. Where commit #3 introduces new class that is going to be removed in commits #6 and #7.
"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.
Sometimes I notice myself go a bit too long without a commit and get nervous. Even if I'm in a deep flow state, I'd rather `commit -m "wip"` than have to rely on a system not built for version control.
I would have pressed Ctrl-Z in my editor like mad until I got the file. If I was using vim I could even grep for it through my history files, thanks to vim-persisted-undo.
Earlier quoted context omitted.
Its a matter of priorities. Its cheap and fast and there is a chance that it will be OK. Even just OK until I move on. People often make risky choices for those reasons. Not just with IT systems - the crash of 2008 was largely the result of people betting (usually correctly) that the wheels would not fall off until after they had collected a few years of bonuses.
I do not know who is doing the math, but deleting production data does not sound very cheap to me...
That is why I chose to compare it to the 2008 crash. The people who took the decisions to take the risks that lead to it came out of it OK.
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…
But the fact is your complete PR commit history gives most people a headache unless it's multiple important fixes in one PR for conveniency's sake. Happens at least for me very rarely. Important things should be documented in say a separate markdown file.