Cease and desist for companies and government agencies misusing git

Cease and desist for companies and government agencies misusing git

[Mark Bauermeister]

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.

Re: Cease and desist for companies and government agencies misusing git

[Nico Williams]

On Thu, Oct 30, 2025 at 04:27:10PM +0100, Mark Bauermeister wrote:
> 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.

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
-- 

Re: Cease and desist for companies and government agencies misusing git

[Junio C Hamano]

Mark Bauermeister <warfan2007@gmail.com> writes:

> 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.

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.