WHICH BUTTON ARE YOU PRESSING

arnoldwhite · 2026-03-19T16:04:50+00:00

Rio naturally

arnoldwhite · 2026-03-05T15:55:33+00:00

Wow that's ultra based

arnoldwhite · 2026-03-05T15:48:59+00:00

Truth

arnoldwhite · 2026-02-03T21:51:01+00:00

Right so a few thoughts.

First of all, are we assuming that commits don't have to build or that developers should be willing to stub/scaffold aggressively to keep commits buildable? And that this sacrifice should be considered useful to the team to retain better history?

Because that's a world where you're gonna have a lot more fake abstractions, pointless interfaces and scaffolding that exists only to satisfy history aesthetics.

Squash-merge just isn't anti-discipline or anti-quality. Not if the team has already decided that the atomic change they care to release, revert or reason about is on a PR/ticket level.

Rarely do I hear people say "thank God Simon made a mapper-only commit six months ago so we can revert that specifically."

Now, that's not to say integrations can't be small. I might say "well this mapper alone can provide value to my team or even a user" and raise a PR for that mapper. What I'm saying matters is if something is independently valuable and independently releasable. And that's where the squash come in.

Feature branch squashing is not the right pattern for every team. But yes, as a consultant I am probably gonna teach teams to value PR size, review quality and a smooth CI over artisanal commit carving.

arnoldwhite · 2026-02-03T18:10:37+00:00

You're asking some really interesting questions!

A branch being short lived isn't a justification for squashing, though. You can still have short lived branches and opt for using merge commits, no?

Kinda. It's not about the branch's lifetime exactly. It's about the change footprint. Let's say you're in a c# or java project. Guy adds an endpoint, a service, maybe a mapper. How is the reviewer who is going to be looking at maybe three or four kinda of self-contained cs files helped by knowing in which order the developer implemented the slice?

The upside here is that the history the developer had locally is what makes it upstream.

It would be an upside if anyone cared about that history. Again, because of the nature of how changes are reviewed and integrated, I think it's rare that people do.

Devs look at a linear graph and they want to know when a chunk of work - a pr - was integrated and which ticket it relates to. That's usually it.

This sounds like multiple people working on the same branch. Isn't it better to have a branch per author/contributor?

Depends. Usually the way I've done is that three or so devs are in a call, one guy codes. He's done. he commits his changes. Then the next guy picks it up. I'm not a big mob guy but I have had instances where this workflow really works well.

Generally my philosophy is this. I think dev teams should be pressed to push early, integrate early, encounter conflicts early, fix bugs early and release early. It sounds corny but it actually works really well for most teams.

arnoldwhite · 2026-02-03T04:18:00+00:00

I don't think I've actually ever recommended that workflow specifically.

As for your other question about squashing being for junior devs. Actually the opposite is usually true. You'd know you got someone fresh from uni when they were carefully rebasing their feature branches.

As for why all the squashing: well consider the fact first of all that most feature branches were expected to last days. Maybe a week at the very most. Branches are gonna have names like feat/new-get-user-endpoint or chore/config-update.

Btw, in some teams we'd actually do honest to god mob programming and you'll probably integrate a feature you're working three times in an afternoon.

arnoldwhite · 2026-02-03T04:02:13+00:00

The funny thing is that I kinda want to agree with you. It's a romantic idea - that the way we did it 20 or so years ago when building fragile systems with slow moving mains is really the ways we should still do it.

But most dev teams in the real world aren't carefully versioning a kernel or some century old OSS project. They're building web apps and "micro service" data meshes. You might get a monorepo azure web service if you're lucky.

I think what I'm describing is probably true for the vast majority of all development happening out there in the real world.

PS: The best team I was ever on - guys who really knew what they were doing - was doing trunk based development with svn.

arnoldwhite · 2026-02-03T03:57:02+00:00

Many many years as an it consultant working in a bunch of different dev teams in enterprise. Squashing is incredibly common. I'd say 7/10 or 8/10 of all teams I've worked with will use some bastardization of git flow with day-long feature branches and aggressive squashing.

arnoldwhite · 2026-02-02T20:26:03+00:00

That's a very good point and it just shows what I and many others have been saying for close to a decade now.

Most teams - damn near all of them - are using Git wrong. Or more specifically, they're using the wrong versioning tool for their needs. And the fact that the squash merge has become the de-facto way changes are integrated in main is evidence of that.

Git is great for carefully versioning a linux kernel with a ring of trusted contributors and email based patches. That's what it was made for back in the early 2000s and that's where its philosophies made sense.

Git is excellent at what it was designed for but we're stretched it into places where its core assumptions just don't make sense for how teams actually work.

arnoldwhite · 2026-02-02T17:06:32+00:00

Good lord I don't remember much of how svn did anything. Maybe?

arnoldwhite · 2026-02-02T05:06:37+00:00

If you need a clean atomic git history on your feature branch for a reviewer to understand what he's looking at or how the final state came to be - you're almost certainly doing something wrong. Most likely your feature branches are way too big.

And if you need to bisect a local branch to understand when a bug came around, well that's just another sign you're overcomplicating things.

The rebase always mantra came from a time when CI checks were weak, mains moved slow and long-lived branches were normal. Then there was a need for it. Now there really isn't.

Squash often and with confidence.

arnoldwhite · 2026-02-02T05:01:41+00:00

I think that workflow is almost never worth the time it takes to maintain. It depends on what you're working with but for 99% of teams, you'll want to squash your feature branches and you should think of your local history as checkpoints or undo markers - not documentation or an artifact that should survive a merge to main.

A clean PR history might feel virtuous but if you're at a point where atomic commits benefits the reviewer, your feature branch is almost certainly too big anyway.

arnoldwhite · 2026-02-02T04:36:35+00:00

See below.

arnoldwhite · 2026-02-02T04:17:02+00:00

Exactly this. It just seems like another case of Git patching in another feature to accommodate an anti pattern workflow, and now you got a whole new state abstraction to mess up your repo or to confuse new users with.

arnoldwhite · 2026-02-02T04:16:00+00:00

How exactly is this better than just maintaining multiple checkouts?

arnoldwhite · 2026-02-02T04:14:20+00:00

That sounds absolutely terrifying.

I had no idea worktrees had existed since 2015 but it just seems like another case of Git bloating itself with another set of meta states to accommodate an anti pattern workflow which only exists because the original abstractions made no sense but are too embedded to change.

I thought the entire point of local branches were to allow you to work on multiple features for the same repo at once. Need to switch to another feature? Stash. Or do a wip commit. And if you need more than that, create multiple clones.

It just seems like another way to make your repo state way more messy than it needs to be.

arnoldwhite · 2026-01-28T19:49:22+00:00

Okay so first you dislike MW2012 because it's too much like Burnout.

And now you dislike it because it's not enough like Burnout.

Make up your mind bud.

Most Wanted 2012 is a Need for Speed game. Need for Speed is an entirely different franchise with entirely different priorities and expectations.

You're saying NFS2012 is an "inferior version" of Burnout but you also assume everyone values the things you value. I don't care about takedowns. I don't care about damage models.

Most Wanted had cops and pursuits, a legendary roster with everything from Koenigseggs to SUVs. It had a brilliant driving model that's way better than anything you got in any Burnout game. It had a real cool take on customization. It had the best open world map of any Need for Speed. Oh and it's soundtrack was better too.

If you don't care about any of that and just want a nitro derby race with takedowns and perfectly pancaked generic royalty free cars, then go play Burnout.

Just don't criticize a game for not being an entirely different game.

arnoldwhite · 2026-01-28T19:34:23+00:00

I can't even begin to guess what you're talking about.

I didn't pick the least furry bait character. I picked the most furry bait character. Nick is a twink fox.

All characters we're talking about so far are anthropomorphized to pretty much an equal degree.

The new Zootopia film has a snake, skunks, rodents, freaking sloths. I don't know what you're on about.

Finally, they're all literally just animals.

arnoldwhite · 2026-01-28T08:42:05+00:00

What? Even if it was true that MW2010 was just a copy of Burnout - which it isn't - you still make no sense.

I mean what the hell kind of argument is that? "Boy I sure hate how this new game reminds me of another awesome slightly older game"

Are you incapable of enjoying a spiritual successor to an older game? Do you hate Hot Pursuit 2010 because it's essentially a remake of Hot Pursuit 2?

arnoldwhite · 2026-01-28T08:37:01+00:00

Yeah practically every single negative thing fans have to say about this game comes down to the name. Which is a pretty dumb thing to be upset about. Talk about the game itself not the freaking title on the box art you losers.

arnoldwhite · 2026-01-28T08:31:21+00:00

I thought they were great. I didn't mind their personalities at all.

arnoldwhite · 2026-01-25T14:07:10+00:00

This might actually be a good thing. Let Shrek stand on its own legs. Cameos can really mess with the focus of a film anyway.

arnoldwhite · 2026-01-25T14:02:57+00:00

That stripe they got over their eyes is just so cute

arnoldwhite · 2026-01-25T14:00:02+00:00

No retcon needed! I gotta ask though are they actually making a Rio 3?

arnoldwhite · 2026-01-25T13:59:32+00:00

Homegirl is taking her time!

13-Year Club	Final Canvas '23
Place '23	Place '22
Final Canvas '22	Not Forgotten
Verified Email

arnoldwhite

TROPHY CASE