Listening to the Trash Future team describe CulturePulse.ai and the digital twin profile created for entire populations seems very very reminiscent of “The Red Men” by Matthew de Abaitua which didn’t get the attention it deserved but was quite prescient.

https://trashfuturepodcast.podbean.com/e/waltz-with-the-sims/ (minute 23 and on)

Elements from the book such as the corporation known as “Monad” (!) and robotic public service utilities called “Dr. Easy” are looking back from our current hellscape period a bit too on the nose.

See Dr. Easy act in this short film: https://vimeo.com/68368877

“Squashing destroys this information. I’ll take a merge with 1000 +50/-50 commits over 1 squash every. single. day.”

I’ve been hammering on this fact as well that it’s silly to use git and then throw away so much information that you could use later. But then again most people don’t know git bisect exists.

I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I’ve typed up this response so many times that I’ve decided to just put it in a gist so I can reference it whenever it comes up again.

I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:

I prefer merge and creating a merge commit because I think it best represents true history. You can see the merge point, you can see all the WIP commits the developer went through. You can revert the whole merge easily (git revert -mN ). I create merge commits more than 9 out of every 10 PRs.

I also believe having more commits makes git bisect better, as long as every commit builds. I hate hate hate when I bisect a project only to land on a single squashed commit from a single PR that is like +2000/-500. That is… not helpful at all. I want to bisect and land on a commit thats at worst like +500/-500. At worst. Ideally I land on a commit thats more like +50/-50. Then I can say “ah hah,the bug is there.” Squashing destroys this information. I’ll take a merge with 1000 +50/-50 commits over 1 squash every. single. day.

This strategy depends on good hygiene by the developer keeping every commit building. I follow this rule 99% of the time (I make mistakes, but I try very hard not to). In OSS, you can’t really control this and I’ll sometimes end up fixing up commits for people (using interactive rebase prior to making a merge commit). In a professional environment when I was an engineering leader, I would generally expect engineers I worked with to keep every commit buildable.

I do squash though when a PR has a bajillion tiny “WIP” “WIP” “WIP” commits but is really aiming towards one goal with a relatively small diff. That’s my squash use case. I’m careful when squashing to rewrite the commit message so it is descriptive. The default squash commit message created by Git and GitHub is not good (it just concatenates all the squashed commit messages, usually a series of “WIP”).

If you have a big diff AND a lot of “WIP”, then I rebase (interactively), and selectively squash and reorder commits where it makes sense. I tend to expect developers to do this and care about their commit hygiene, but unfortunately a lot of developers aren’t that comfortable with Git. In the OSS world, I do it for them. When I was an engineering manager back in the day, I’d expect engineers I worked with to have this knowledge.

On this last point, I also tend to use a Git GUI client for large interactive rebases. I’m extremely comfortable with the Git CLI but when I’m interactively rebasing a very large PR (say, 50+ commits) with a large number of changed lines, I find using a GUI to be helpful. I’m on macOS so I use Tower. This is the only situation I actually use a GUI, though.

Just some more German insanity from the anti-Deutsch group that I have to archive here for when it may come in handy later.

Fragment Ones and Tooze: Live from Berlin – Lindner

Given the current developments around the German debt brake, I think it’s good to refer to this bit about German financial politics and Adam Tooze’s initial prediction (FT, Zeit) that Christian Lindner as finance minister would not be good.

Fragment from around 45:00 clipped below:

“We got quite a lot of shit for doing that actually. Not entirely popular with my German colleagues. ‘Nicht zum Volkskörper zugehörig’ is a phrase that was used. ‘Wie trauen sie sich ein solches Urteil zu.’
Not belonging to the body politic of Germany. How dare you make a judgement like that.
We don’t have any reason to regret it. We were clearly right.

Last week I was making a presentation and I came across Deming and his principles. I have often gotten the question: “If you don’t measure X, then how will you know we’re doing well or improving?” which I always felt was misguided.

It turns out that Deming was way ahead of me there, he says: “Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.”

Leadership is always the key.

https://en.wikipedia.org/wiki/W._Edwards_Deming#Key_principles

John Ganz on nationalism and reducing humans to insects.

A warm, comfortable death for you, and a violent, cold, and terrible death for the other guy. It choses being subsumed in a mass to avoid the terrible difficulty of remaining human that rises to the fore in tragic moments like this one. When I die, I hope it will be here in New York, the promised land, surrounded by my brothers: all the different peoples of the world.

Above all, I refuse to become an insect or look on others as insects.