Cease and desist for companies and government agencies misusing git

Ok, this post (as well as the title. As much as I wish we could prohibit such institutions from using our products) is partially tongue in cheek, partially me venting and partially asking the community for ideas on how to properly educate the vast masses of "professional" developers still unaware of the soul crushing damage their workflows (that barely work and definitely don't flow) cause to others.

Earlier this year I got hired by a Swiss government agency. My late mother was incredibly happy and proud of me at the time and knowing that I just got bullied out of that job and finding myself once again in the unemployment line is weighing heavily on me.

Long story short. The guy who was responsible for my firing spent a good 4 months journaling my work and harassing management behind my back only to blow up while on the phone with me, accusing me of such heinous crimes as sending a PR from a fork (at a time I didn't have write access to the main repository...) and *gasp* REBASING.

This dude is convinced (to a religious fervor) that Linus Torvalds was possessed by a demon when he came up with `git rebase` and that in order to defeat the devil, we need to plaster merge commits EVERYWHERE.

His workflow is thusly:

- Create new feature branch based on the master or release branch (this is fine)
- Make changes
- Create PR (all PRs end in a merge commit, btw. This is fine but
makes his git behavior look even more unhinged)
- Check for changes on master/release and create a merge commit on his
branch (there's no logic behind this. He isn't creating a "logical
checkpoint", he just generally runs merge every time)
- If the PR doesn't get approved for a while, he'll keep creating more
merge commits
- Rinse and repeat this for every single feature branch under his
control. Merging merges into his merge (insert Pimp my Ride meme)
- Once the release PRs have been completed, merge (with a merge
commit, naturally...) the release branch into master.

Today I've counted 8 merge commits on changes that amount to about 20 LOC.

I don't wanna live in this world anymore. Beam me up, Scotty!

/end of rant

Is it time for an online campaign ala "Merge commits considered harmful"?

I have nothing against a merge commit being the result of a successful PR but people spamming merge commits are ... something else.

On Thu, Oct 30, 2025 at 04:27:10PM +0100, Mark Bauermeister wrote:

That's nuts!

By the way, Linus did not invent rebasing. We used rebasing at Sun Microsystems, Inc, (RIP) since 1992. We didn't call it that, but merge commits were absolutely verboten (they were called "merge turds").

The Solaris engineering organization had thousands of developers, and often tens of large projects with their own "gates" (forks), and everyone rebasing all the time, and the end result was linear, easy to understand history.

Rebase workflows are the only workflows that scale to such project sizes as Solaris used to be, or as Windows, Linux, etc. are now.

Nico

Mark Bauermeister <warfan2007@gmail.com> writes:

There do exist people who make pointless back-merges into their topic from the trunk, just like there are those who pointlessly rebase their topic every time they notice that the trunk got updated. Both are bad, even though constant rebasing would hide the fact they were rebased and what was integrated at the end was less well tested than what was originally written, so in a sense it may be worse.

These people need to learn that they can make trial merges every once in a while so that their topic can be used with more recent tip of trunk than where they forked from, and that they do not have to keep these trial merges in the history.