Linus Torvalds: “GitHub creates useless garbage merges” (opens in new tab)

What would you rather see? That he just avoid expressing any opinion that might make people question your status-quo? Muddy his own message by weighing down his emails with hedging and qualifying statements that are - at best - superfluous to his target audience?

I'd love it if one of my juniors was tuned in enough to read this and realize there is more to git than github. And maybe they even start learning how to use that tool beyond the lowest common denominator of git knowledge that most people skate by with.

Of course it might mean steering them away from a rash decisions like misinterpreting this email, or wanting to leave github just because someone pointed out it wasn't perfect. But that's what makes them junior. It's my job to make them better than that.

>which ends up being a lot of work for no material gain for my org.

If you would just paternalistically tell them no, or would give a mentoring answer but don't see the value in that, then there is a workplace problem to address. Either you're hiring too junior for what you're willing to support on the team, or you need to reconsider your role within the team.

If he can roll out a kernel and distributed version control system, listen to him. Otherwise, it's time to have the talk about cargo culting.

When he has a list of complaints, that is his strong reaction. And why would he need to go stronger?

And yeah, it was more effective. You just have to remember the topic is your code not your person - they are 2 entirely different things. i.e. Brendan Eich is a wizard but javascript started out as a smoking pile of shit.

In The graphing calculator story Ron Avitzur mentioned the other devs saying "It doesn't even suck" which was the highest possible praise.

Also, not that chromium did something different. They reference tons of internal bug IDs, change IDs, and this commit msg also has an URL with the non-standard domain go (no TLD):

https://github.com/chromium/chromium/commit/8b4b1831e333a43d...

If a project is renamed or relocated from one name to another it might (and should) preserve issue and merge related information and discussion, but any full URLs will have changed, making full URLs fail in specific cases. Using any form of shortened sequential identifiers will fail when referenced in commits merged in from forks of the project that have their own conflicting identifiers.

To solve this in any real way there needs to be a way that when a project is forked it carries information about issues and merges with it, and when commits from that fork are merged back into the main project, or merges from a fork of a fork are merged all the way back to the original project, all metadata about those merges are carried to the original project.

Linus' argument is that the correct place to store that is in the merge commit's message. That it is the responsibility of the person doing the merge to provide that information, and that GitHub does a bad job of providing tools to do that.

https://twitter.com/vmulps/status/1386717970458677250

I think you can only link a GPG public key though.

Oh that's easy. You bring all maintainers in the one place, disconnect their internet and wait for the white smoke.

In fact I once did a PR moving around some files which is visible with multiple commits (move file commit, edit file commit) which was replaced by a sqiash commit that deletes files and adds one with modified content.

As an industry, we should be nudging people away from those bad habits. Instead, the "squash merge" feature nudges them in the opposite direction. It disincentivizes careful commit commit messages and encourages general disregard for the commit log.

Collaboration requires good communication. For programmers, that means:

- writing clear code

- commenting your code

- documenting your code

- writing a clear summary in the PR description

- organizing your changes into cohesive, (mostly) self-contained, reviewable units -- expressed as independent commits in the version history

On that last point: The commit log is something worth curating, tending to it with the same care you would use for the other points.

Yes, PRs are often small and self-contained enough that it shouldn't be subdivided into multiple commits. But just as often, it's clearer to use multiple commits which can be reviewed in sequence, rather than in one big chunk.

In the latter case, it's incumbent on the PR author to present a logical, clean commit history. If you wrote four commits but two of them are inseparable, then squash those two before you submit the PR. Commit messages like "fix typo from last change" are completely unacceptable in a PR. That sort of thing is fine in your own repos, outside of any review process. But when sharing code with others? No way -- that's inconsiderate with others' time, and pollutes a valuable data stream (the commit log).

But hey, if there's a good chance that all your commits will be squashed anyway, then why bother curating your commit log at all?

Instead of letting bad commit messages slide and simply squashing them, we should gently insist that PR authors fix their commits on their end. Their next PR will be better for it.

In the past, I've been occasionally annoyed when my carefully crafted commit log was simply squashed by a PR. I had intended the commits to be reviewed one-by-one. And if a bug is discovered in one commit later on, it would be clear which lines ought to be reverted, and which should stay unchanged. All of that care gets thrown out by a squash. Grr...

Edit: but it really is a niche use case. Count the number of developers working, the number of lines written, for projects that are not the special snowflake of the Linux kernel. Line of business apps. Consultoware. Fuggin' code bootcamp students selfishly using other people's open source projects for their grad advancement. All this code that nobody, maybe not even the people writing it, cares about. Git is the wrong tool for those jobs, but because Torvalds wrote it, it must be good.