On Sun, Jan 04, 2026 at 11:17:45AM +0900, Junio C Hamano wrote:

Harald Nordgren [off-list ref] writes:

quoted

Isn't programming always bit of drunken-man's walk?

Yes, but the point is that other people do not have to see you
taking roundabout route (or for that matter, they do not have to see
you coding in your bathrobe like Linus, even if it may be true you
;-).

Sun Microsystems, Inc. used a rebase workflow from 1992 to its end
(RIP).  Thousands of developers worked with stricly linear history
(merges were not allowed!).  Large team projects that had to have their
own alternate repositories and do the Teamware equivalent of `git rebase
--onto` periodically.  There was no branching, only forking.  Forks were
kept for backporting and for history archival purposes.

It worked like a charm.

Merge workflows are -IMO- toxic and obnoxious.  I do NOT want to see any
programmer's "drunken-man's walk", unless it's because I'm interviewing
them.  There is no value to preserving that.

When other developers later need to figure out what you really
wanted to achieve so that they do not break your intention while
they update your code to fix bugs in it and/or adding new features
on top of it, it would be far easier for them to work on a clean
history.

Hear hear!

Strictly linear history makes it much easier to understand what's going
on.  The only merge turds I would allow are fast-forward ones where the
purpose of the merge commit is to document push boundaries in the commit
history, but even this I don't like.

Nico
--