Linus Torvalds: “GitHub creates useless garbage merges”(lore.kernel.org)
lore.kernel.org
Linus Torvalds: “GitHub creates useless garbage merges”
https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5Kc50y5BceL8Q8=aL0H3Q@mail.gmail.com/
109 comments
These has two problems, first it will impose you to use the official or a compatible GitHub interface, not the command line or whatever git GUI interface you want. Even with that, it is impossible to use offline, while your git history is local and can be consulted whenever you want without a connection, and you can make whatever changes you want and push them when you have internet access.
The second problem is that it's not portable, it's something internal of GitHub, that is fine till you use GitHub, when you need to migrate to another server, or host your own git repository, for reasons (GitHub changes plans, GitHub closes down, GitHub no longer wants to host your project, etc) what do you do?
The second problem is that it's not portable, it's something internal of GitHub, that is fine till you use GitHub, when you need to migrate to another server, or host your own git repository, for reasons (GitHub changes plans, GitHub closes down, GitHub no longer wants to host your project, etc) what do you do?
These issue numbers are non-portable even within github! Two repositories may have the same commits in them but different sets of issues.
My favourite is when someone collaborates on a PR and they create PRs for the PR's branch in the forked repo. That repo has its own numbers so you'll end up with merge commits referencing PR #4 in the main repo.
this came very close to exposing private repo details to the wrong users for me recently
currently trying to find an exploit using this 'feature'
currently trying to find an exploit using this 'feature'
Because forks are GUI sugar for refs in the main repo.
This is also why Actions have convoluted security implications.
This is also why Actions have convoluted security implications.
No I didn't mean the "you can replace the fork's URL with the main repo one and make the commit seem part of the repo". That's a weird github oddity to keep in mind, but not the issue I meant. I meant when that PR including its merge commits gets merged. Then those commmits become proper members of the main repo.
I don't work for GitHub, but I would eat my shoes if GitHub made any conscious choice at all in their design regarding keeping people on the web UI. It sounds almost exactly like a decision made to keep some sort of backwards compatibility without having to do any extra engineering, stray far from vanilla Git, or make the user experience worse for regular users.
The issue with full URLs is renames of user or project names. I don't trust the inbuilt redirection support of Github this much. Plus, tools that don't shorten full URLs would get extremely long lines in their commit messages. I think the Github issue numbers translate 1:1 to Gitlab if you use the Github->Gitlab exporter. If you used full URLs, it would either have to keep the URLs, or change commit hashes, neither a really nice option.
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...
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...
> 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):
The kernel does that too. Those key-value pairs are called "trailers", and are semi-standardized at https://git.wiki.kernel.org/index.php/CommitMessageConventio...
The "git interpret-trailers" command exists to work with this kind of data.
The kernel does that too. Those key-value pairs are called "trailers", and are semi-standardized at https://git.wiki.kernel.org/index.php/CommitMessageConventio...
The "git interpret-trailers" command exists to work with this kind of data.
Having a number short-form is a de-facto standard across most "version control+issue tracker" services.
For nearly all cases it's good enough, projects like the Linux kernel are in the end an exception wrt. their requirements and workflow. Most project are just hosted in one place so the shorthand is always clear, and has the benefit of not being "broken" if a project is renamed/moved.
Furthermore GitHub always allows the user to specify the commit message, it just prefills some hint. But it can't really know your style of using git so it can't do much more then just prefilling the hints. But you can always write them the way you want to filling in all the details needed.
Through IMHO the problem are non-ff git merges in general, not only do they motivate bad commit messages but also does "not having merge conflicts" in no way mean there is no problem. I had more then one time where a "no conflict" git merge introduced bugs.
Projects like Linux are a bit special due to the size, number of contributers and sizes of contribution.
But for most projects I can just strongly recommend to only allow FF merges and locally rebase branches on master if it doesn't work. Preferable with users using interactive rebases to create nice commit histories, alternatively squashing works to but git is just _bad_ at squashing and so are tools based ontop of it (e.g. GitHub).
For nearly all cases it's good enough, projects like the Linux kernel are in the end an exception wrt. their requirements and workflow. Most project are just hosted in one place so the shorthand is always clear, and has the benefit of not being "broken" if a project is renamed/moved.
Furthermore GitHub always allows the user to specify the commit message, it just prefills some hint. But it can't really know your style of using git so it can't do much more then just prefilling the hints. But you can always write them the way you want to filling in all the details needed.
Through IMHO the problem are non-ff git merges in general, not only do they motivate bad commit messages but also does "not having merge conflicts" in no way mean there is no problem. I had more then one time where a "no conflict" git merge introduced bugs.
Projects like Linux are a bit special due to the size, number of contributers and sizes of contribution.
But for most projects I can just strongly recommend to only allow FF merges and locally rebase branches on master if it doesn't work. Preferable with users using interactive rebases to create nice commit histories, alternatively squashing works to but git is just _bad_ at squashing and so are tools based ontop of it (e.g. GitHub).
If the data is not stored in the git repo itself there is no workable solution. Any offered standard is just a bandaid on the problem.
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.
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.
Note that if you like to keep reference to merge requests and the "commit grouping" that merge commits allow, you may very well use FF-only merges with merge commits. You can then use things like `git log --first-parent` to have sort of high-level "merged MRs" view on your history, which may be useful for some workflows. GitHub's (and GitLab's) history view is pretty bad, but that doesn't mean all history views are so featureless as these Web UIs ;)
I had to google what Torvalds currently do:
..."What is your job?" Torvalds replied, "I read and write a lot of email. My job really is, in the end, is to say 'no.' Somebody has to say 'no' to [this patch or that pull request]. And because developers know that if they do something that I'll say 'no' to, they do a better job of writing the code." [1]
Do we have any idea what will happen to Linux once Torvalds is not there? Is there any example in history of OSS development as to what happens when BDFL [2] is not there anymore?
[1] https://www.zdnet.com/article/linus-torvalds-im-not-a-progra...
[2] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
..."What is your job?" Torvalds replied, "I read and write a lot of email. My job really is, in the end, is to say 'no.' Somebody has to say 'no' to [this patch or that pull request]. And because developers know that if they do something that I'll say 'no' to, they do a better job of writing the code." [1]
Do we have any idea what will happen to Linux once Torvalds is not there? Is there any example in history of OSS development as to what happens when BDFL [2] is not there anymore?
[1] https://www.zdnet.com/article/linus-torvalds-im-not-a-progra...
[2] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
There is no publicly acknowledged succession plan but Linus has previously commented it may take a few months for the community to work out how to move forward but he seems confident they will.
It’s just that no one in their right mind would want to do Linus’ job. It’s miserable and stressful; he only does it because he’s been doing it for 30 years and it’s his baby.
The outcome will be interesting to be certain.
It’s just that no one in their right mind would want to do Linus’ job. It’s miserable and stressful; he only does it because he’s been doing it for 30 years and it’s his baby.
The outcome will be interesting to be certain.
> There is no publicly acknowledged succession plan
Oh that's easy. You bring all maintainers in the one place, disconnect their internet and wait for the white smoke.
Oh that's easy. You bring all maintainers in the one place, disconnect their internet and wait for the white smoke.
At best, we can just hope that Greg has the same resilience as Linus ~ and that Greg's chosen successor also has the same grit
For those unfamiliar, Greg Kroah-Hartman is the maintainer of the Linux stable branch since 2013: https://en.wikipedia.org/wiki/Greg_Kroah-Hartman
> Is there any example in history of OSS development as to what happens when BDFL [2] is not there anymore?
The Python BDFL announced his resignation three years ago, so that project might serve as an example.
https://lwn.net/Articles/759654/
I think it will be a while before we see the long term effects of Guido's departure, but I already miss him. The few interactions we had left me feeling that he was good at choosing his yeses and noes appropriately.
The Python BDFL announced his resignation three years ago, so that project might serve as an example.
https://lwn.net/Articles/759654/
I think it will be a while before we see the long term effects of Guido's departure, but I already miss him. The few interactions we had left me feeling that he was good at choosing his yeses and noes appropriately.
We can look at projects like FreeBSD and NetBSD. Perhaps Linux kernel development will go to a similar board model?
When I train developers on `git` in combination with GitHub, I emphasize that `git` the tool was written for a specific goal. Linus wrote it to replace BitKeeper for the express purpose of collaborating on the maintenance & development of the Linux kernel.
The biggest problem is when developers who do not really understand version control at all (there are a lot of them -- they tend to think of it as a "save" mechanism) are allowed to use all the features of GitHub and can only do their work with buttons.
For example, it is common for some developers to think that there are only two options when dealing with merge conflicts: "Accept theirs" or "accept ours" when, in reality, most real merge conflicts require a synthesis. Now, add to this the fact that such developers barely write commit message (seen too many projects with only "merge X and Y", "update", "fix bug", "implement feature" etc). The situation gets worse.
Soon, you end up with a project where the only tool for locating any issue becomes `git bisect`.
The biggest problem is when developers who do not really understand version control at all (there are a lot of them -- they tend to think of it as a "save" mechanism) are allowed to use all the features of GitHub and can only do their work with buttons.
For example, it is common for some developers to think that there are only two options when dealing with merge conflicts: "Accept theirs" or "accept ours" when, in reality, most real merge conflicts require a synthesis. Now, add to this the fact that such developers barely write commit message (seen too many projects with only "merge X and Y", "update", "fix bug", "implement feature" etc). The situation gets worse.
Soon, you end up with a project where the only tool for locating any issue becomes `git bisect`.
Yes, some devs just can't merge. Even worse, IntelliJ & co have this "magic merge" button, that resolves conflicts automatically, but the results are usually a mess, esp when merging complex features. But because lazy devs are lazy, they just smash that button, commit, push without testing locally and then move on to the next topic. Naturally, we've had countless CICD failures which were attributed to "merging in git is sooo broken" ...
Curious that this comes on front page along side the whole Atlassian / Jira debate.
One of the major reasons Github does not / cannot do commit messages the way Linus likes is that the reasons why odd is changed are in and supposed to be in the ticket tracker (where non-coders / committers can view / comment / approve.)
This is not a technical fix that github can make - this is a fundamental split about where the power lies - most companies do not have the final say, the source of truth, in their codebase and consequently their repos.
Linus is on the side of history here. But for those of us coders living in ticket trackers for our daily job, it's a serious culture shock. For non- coders it's an existential threat.
On a separate note, I think there is a space for using hashes to compress tickets and all the ancillary evidence and sign offs, into one artifact, and then reference that in the repo commit. But I just can't see it in my head
One of the major reasons Github does not / cannot do commit messages the way Linus likes is that the reasons why odd is changed are in and supposed to be in the ticket tracker (where non-coders / committers can view / comment / approve.)
This is not a technical fix that github can make - this is a fundamental split about where the power lies - most companies do not have the final say, the source of truth, in their codebase and consequently their repos.
Linus is on the side of history here. But for those of us coders living in ticket trackers for our daily job, it's a serious culture shock. For non- coders it's an existential threat.
On a separate note, I think there is a space for using hashes to compress tickets and all the ancillary evidence and sign offs, into one artifact, and then reference that in the repo commit. But I just can't see it in my head
> Linus is on the side of history here.
Through not seldom the source of truth is also hidden somewhere in the Linux mailing list.
Similar a (insane) high amount of projects on GitHub and in companies will hardly ever use the history besides a last few commits. Sure git blame is a thing, and so is bisect but how often is it used on projects besides large open-source projects?
Through not seldom the source of truth is also hidden somewhere in the Linux mailing list.
Similar a (insane) high amount of projects on GitHub and in companies will hardly ever use the history besides a last few commits. Sure git blame is a thing, and so is bisect but how often is it used on projects besides large open-source projects?
[deleted]
From the headline, I thought this would be about github’s squash merges, which represent an extreme anti-pattern to any sane developer.
can you explain further? In my experience other people's half-baked commit messages are just noise while the pull request is more carefully written, so the squash merge is more intelligible. Additionally, the PR is typically used as the "atomic" code change rather than the individual commits.
Even if they have shitty commits, it barely matter if its hidden behind a merge commit. On the off chance that squashed commits wouldve been useful, I much rather have it than not.
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.
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.
I agree: Many people have half-baked commit messages. And many erroneously assume that a PR is always a single atomic code change, rather than a sequence of pseudo-atomic changes.
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...
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...
One of the few times I agree with Linus.
I think Linus generally has well reasoned technical opinions. I find it a little unusual that you decided to communicate that it's rare that you agree with him.
I think it's much more common to say his communication style has problems. I think he has really good intuition on technical stuff.
This is not to say Linux or Linus are perfect, but you can usually pick out certain of his opinions and find them to be pretty grounded.
I think it's much more common to say his communication style has problems. I think he has really good intuition on technical stuff.
This is not to say Linux or Linus are perfect, but you can usually pick out certain of his opinions and find them to be pretty grounded.
Linus is why I generally don't use Linux unless I absolutely have to.
I guess looking at your user info you like BSD? I like *BSD better than Linux. But it's not due to personal feelings about Linus, and I respect his talents and good eye for a lot of technical things.
Yep, been using FreeBSD on the Desktop since 1996.
I've used Linux for plenty of things, but I tend not to unless I need something thats written specifically for Linux.
There's very little I need Linux itself for.
My issues with Linus were a few design decisions, how stuff gets into the kernel, how the distributions work, how things are poorly tested/etc.
Sadly now that FreeBSD is using ZoL I'm encountering a bunch of problems related to that :(
Sadly now that FreeBSD is using ZoL I'm encountering a bunch of problems related to that :(
I mean, he’s usually right. Even if historically the way he has expressed himself has not always been the most agreeable.
I'd say more like "close enough", which is frankly good enough for most people. I'd go as far as to say that Linux's userbase exists despite Linus's personality and intelligence.
Now, I wish there were a guide to creating proper pull requests. From what I read, I got some things, but not a straightforward or actionable path. The only clear thing is the unmistakable feeling of not doing PRs properly.
There's https://www.kernel.org/doc/html/latest/maintainer/pull-reque...
Note that you generally don't send pull requests when contributing to Linux unless your changeset is unusually big, so pull requests are usually only used by maintainers to forward their stuff to other maintainers. Regular contributors submit patches instead: https://www.kernel.org/doc/html/latest/process/submitting-pa...
Note that you generally don't send pull requests when contributing to Linux unless your changeset is unusually big, so pull requests are usually only used by maintainers to forward their stuff to other maintainers. Regular contributors submit patches instead: https://www.kernel.org/doc/html/latest/process/submitting-pa...
I still prefer github's UI and PR style over those ugly kernel mailinglists, where there is no merge status and no good CI integration and no good search unless you force yourself into using some complex mail setup.
[deleted]
Is there a way to sign your merge commits on GitHub? How do they get trusted?
Yes. Here's an excerpt from their documentation on <https://docs.github.com/en/github/authenticating-to-github/m...>:
> GitHub will automatically use GPG to sign commits you make using the GitHub web interface
> GitHub will automatically use GPG to sign commits you make using the GitHub web interface
It’s even worse, if somebody rebase-merges a pull request that you authored (thereby creating a new commit that you did not author), GitHub will show you as the author (without a separate committer, like it normally does when author and committer differ), and put “verified” next to it, which usually means that they verified that it was signed by your GPG key, but in this case, it means that the commit was created by GitHub.
https://twitter.com/vmulps/status/1386717970458677250
https://twitter.com/vmulps/status/1386717970458677250
Says it signs the commit with its own key. I guess you have to trust GitHub.
Well, yes. The question was whether you can sign _on GitHub_, so your private key has to be available to GitHub. You can always sign locally if you don't trust GitHub.
What else would they be signing with? They don’t have your key obviously
Well that was my point - I wonder why we haven't set up a system that lets me sign the merge commit. Otherwise it's a commit purported to be authored by me but when you look it's actually signed by someone else.
You can sign your commits with a GPG key, in your GitHub settings you can then link a GPG key to your account.
You can then make it that GitHub shows any non signed commit as unverified and at a project level not allow PRs that contain unsigned commits.
You can then make it that GitHub shows any non signed commit as unverified and at a project level not allow PRs that contain unsigned commits.
> you can then link a GPG key to your account
I think you can only link a GPG public key though.
I think you can only link a GPG public key though.
Github is signing them with their own key when you merge through the web UI
Signing commits is a local affair, you don't want to be uploading your private key to Github. You sign locally via command line and then push to Github where they get verified with your public key.
[deleted]
Local (and preferable with HSM) is the only way, or else it would undermine the point of signing commits.
Through if you just want commits to be signed, then GitHub does it for you as it (always??) signs commits created by their UI/System with their key.
Generally I would recommend FF-Only commits (independent of signing) and local auto-signing of all commits.
Through if you just want commits to be signed, then GitHub does it for you as it (always??) signs commits created by their UI/System with their key.
Generally I would recommend FF-Only commits (independent of signing) and local auto-signing of all commits.
Sounds like it would be easy for Github to fix? No? Yes?
Does this bother a lot of people? Has anyone ever opened an issue on this? If not I say why bother...Linus is hard to please
Github already offers several way to incorporate PRs, including squashing and rebasing. It also offers repo admins the ability to _forbid_ maintainers from using the default Github merge. I think that's plenty of work dedicated to fixing this issue.
That's just a preference issue.
If you just pick rebase instead of merge from the UI the commits will be merged without that "meta commit".
No need to get all emotional
If you just pick rebase instead of merge from the UI the commits will be merged without that "meta commit".
No need to get all emotional
He is not wrong
Behind the rage, there is good wisdom in Linus’s rants.
Clickbait tittle.
It's not the content of what's merged that he's complaining about, it's the default formatting from the GitHub UI (no commit message for instance).
It's not the content of what's merged that he's complaining about, it's the default formatting from the GitHub UI (no commit message for instance).
How is it clickbait, it’s what he said.
> That's another of those things that I really don't want to see - github creates absolutely useless garbage merges, and you should never ever use the github interfaces to merge anything.
> That's another of those things that I really don't want to see - github creates absolutely useless garbage merges, and you should never ever use the github interfaces to merge anything.
The tittle sort of implies that "people contributing from GitHub try to merge garbage into the kernel tree".
[deleted]
He said many things. Picking the one that, out of context, sounds like something irritating and controversial, is the very definition of clickbait.
The definition of clickbait, according to Wikipedia is:
> Clickbait is a text or a thumbnail link that is designed to attract attention and to entice users to follow that link and read, view, or listen to the linked piece of online content, being typically deceptive, sensationalized, or otherwise misleading.
I don't see the title as misleading. I expected to see a kernel mailing list email from Linus where he says what he doesn't like about Github merges and that's what I got.
> Clickbait is a text or a thumbnail link that is designed to attract attention and to entice users to follow that link and read, view, or listen to the linked piece of online content, being typically deceptive, sensationalized, or otherwise misleading.
I don't see the title as misleading. I expected to see a kernel mailing list email from Linus where he says what he doesn't like about Github merges and that's what I got.
I actually read it in the way that Linus meant it — that the issue was with GitHub.
"The very definition of clickbait" is an interesting topic and phrasing. Have you ever noticed that "clickbait" is often shorthand for a summary that somebody disagrees with? Like, if somebody does a summary you can disagree with, even if not maliciously or objectively wrong, people will accuse them of "clickbait". That bad faith is surmised and accusing people of "baiting" is sometimes not the greatest look, but common.
Not really out of the context.
And that thing was probably the whole reason why posting and starting the discussion from this specific url is interesting, as it means a lot while being just little detail.
There is a longer breakdown of the thread here:
https://www.theregister.com/2021/09/06/github_merges_useless...
He also says: "But it also means proper authorship and committer information etc. All of which github entirely screws up." and they link back to an earlier complaint from him about that.
https://www.theregister.com/2021/09/06/github_merges_useless...
He also says: "But it also means proper authorship and committer information etc. All of which github entirely screws up." and they link back to an earlier complaint from him about that.
The problem is that Git is used for two things: the Linux kernel and anything else. The Linux kernel has this really weird system of software development where nobody knows anyone else and they want to share all their changes over email. Torvalds, for reasons I can't figure out, only cares about that one, niche use case.
Because that ‘niche’ use case is what he wrote git for, and it just happened to be useful to the rest of us?
whoosh
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.
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.
Whoops, missed the snark the first time though.
For anyone that haven't tried this yet, please have a look at 3-way merging. A number of tools support it, including simple ones like `meld`. I've been using it for a while and it has been a huge help on complicated merges.
Hot take: why do we still care? Linus says something negative about something, big shocker.
This is just the tech crowd equivalent of a tabloid at the supermarket checkout isle, Tom Cruise is secretly a ferret-lover, read all about Bob’s torrid affair with Mallory!
This is just the tech crowd equivalent of a tabloid at the supermarket checkout isle, Tom Cruise is secretly a ferret-lover, read all about Bob’s torrid affair with Mallory!
Because it's fun
That's the biggest thing to learn from bullies like Linus - he hates everything and thinks everyone's an idiot, so where does he go when he actually needs to express something strongly? He can't go anywhere. It's not an effective way to communicate.
I wouldn't dare say we should go back to it but it is how many use to communicate long ago. The mechanism is simple, if you deliver anything yourself you must live up to your own expectations. The louder you moan about everything the more harshly we should examine your stuff. You cant complaint when people ridicule or critique your software if you do it yourself all the time: You've openly invited it!
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.
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.
> You just have to remember the topic is your code not your person
No he definitely attacks people's person.
"You're a moron."
https://github.com/torvalds/linux/pull/17#issuecomment-56599...
No he definitely attacks people's person.
"You're a moron."
https://github.com/torvalds/linux/pull/17#issuecomment-56599...
heh, then he is just a grumpy dick
temp8964(2)
> That's the biggest thing to learn from bullies like Linus - he hates everything and thinks everyone's an idiot, so where does he go when he actually needs to express something strongly?
When he has a list of complaints, that is his strong reaction. And why would he need to go stronger?
When he has a list of complaints, that is his strong reaction. And why would he need to go stronger?
> And why would he need to go stronger?
If he uses his strongest reaction for normal work-day issues like drivers and interface design, where does he go for any potential existential community issues we face in the future?
If something comes up that threatens the future of Linux, and he swears and threatens as usual while trying to warn people about it, nobody will care because 'ah yeah that's just normal Linus'.
If he uses his strongest reaction for normal work-day issues like drivers and interface design, where does he go for any potential existential community issues we face in the future?
If something comes up that threatens the future of Linux, and he swears and threatens as usual while trying to warn people about it, nobody will care because 'ah yeah that's just normal Linus'.
Does he threaten people? And the people that aren't just bystanders will read the thing he says, he doesn't need to punch it up to attract a crowd.
> Does he threaten people?
He uses personal abuse against people. Not sure that counts as 'threatening'.
Really we should always challenge any kind of abuse.
He uses personal abuse against people. Not sure that counts as 'threatening'.
Really we should always challenge any kind of abuse.
When that happens it is bad, yes.
But you're also arguing that he needs to be able to get scarier when necessary, which is a weird thing to argue at the same time?
But you're also arguing that he needs to be able to get scarier when necessary, which is a weird thing to argue at the same time?
> But you're also arguing that he needs to be able to get scarier
No I'm not. The opposite.
If the only tool you know how to use is abuse, then when you need more all you can do is abuse more and more, to the point where you are literally encouraging people to kill themselves.
If you learn other tools you can use them instead when needed and they have an impact.
If I heard Mister Rogers say something was extremely serious I’d stop and listen because he’s a calm and reasonable person. If I heard Linus telling another person to kill themselves I’d think it was him being terrible again but I wouldn’t take notice of what he’s trying to say because he uses that kind of abuse for minor things anyway.
No I'm not. The opposite.
If the only tool you know how to use is abuse, then when you need more all you can do is abuse more and more, to the point where you are literally encouraging people to kill themselves.
If you learn other tools you can use them instead when needed and they have an impact.
If I heard Mister Rogers say something was extremely serious I’d stop and listen because he’s a calm and reasonable person. If I heard Linus telling another person to kill themselves I’d think it was him being terrible again but I wouldn’t take notice of what he’s trying to say because he uses that kind of abuse for minor things anyway.
> If the only tool you know how to use is abuse, then when you need more all you can do is abuse more and more
"If", yes.
Is your argument that because he put abuse into emails, that he must not know any of those other tools? I don't think you've justified that argument.
He could use the same tools anyone else could, in those situations.
And you're still saying that he might "need more" in certain situations, and I don't think he does. He doesn't need to instantly catch your attention via acting unusual. Much like Mr. Rogers would do just fine at telling you about something serious if he used his normal voice / normal presenting voice.
"If", yes.
Is your argument that because he put abuse into emails, that he must not know any of those other tools? I don't think you've justified that argument.
He could use the same tools anyone else could, in those situations.
And you're still saying that he might "need more" in certain situations, and I don't think he does. He doesn't need to instantly catch your attention via acting unusual. Much like Mr. Rogers would do just fine at telling you about something serious if he used his normal voice / normal presenting voice.
I think it's another proof that he has improved. Sure he uses strong language against the problem, but he's clear with what's wrong and why, and how to improve it.
My concern is that tomorrow, I'll have to deal with one of the junior devs bringing up Linus Torvalds' comment as the starting point for a suggestion we leave GitHub, which ends up being a lot of work for no material gain for my org.
Torvalds isn't wrong, and I'm almost certain he didn't mean, "...and therefore everyone should quit GitHub immediately." but people will interpret it that way. And on the off chance he did mean for everyone to quit GitHub, he's then ignoring a cornucopia of value that GitHub provides unrelated to his expertise as the creator of git, which I don't think he's arrogant enough to do, anymore.
Torvalds isn't wrong, and I'm almost certain he didn't mean, "...and therefore everyone should quit GitHub immediately." but people will interpret it that way. And on the off chance he did mean for everyone to quit GitHub, he's then ignoring a cornucopia of value that GitHub provides unrelated to his expertise as the creator of git, which I don't think he's arrogant enough to do, anymore.
>My concern is that tomorrow, I'll have to deal with one of the junior devs bringing up Linus Torvalds' comment as the starting point for a suggestion we leave GitHub
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.
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.
Then you point at the line before his statement that says “GitHub does a lot of things well…”, and say that you use the tool that best fits your development process, which is GitHub. The kernel uses a different development process which requires all of the information about a change to come from the commit message, making GitHub’s merge messages which rely on having access to other tools besides Git useless.
> I'll have to deal with one of the junior devs bringing up Linus Torvalds' comment as the starting point for a suggestion we leave GitHub
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.
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.
Because he has the street cred to not be diplomatic or political about an opinion. Agree with him or not, he conveys an idea about tech that draws from an incredible intuition and experience, each building on the next and showing an evolution of his thought. He doesn't worry about being "cancelled" and obscure down things with defensive caveats, or being shunned for liking some unpopular concept.
He also friggin’ wrote git. If there’s anything he’s allowed to have strong opinions on, it’s git (and Linux, obviously).
Architects shape often by saying no and the architecture of Linux and it‘s ecosystem is paramount to the tech industry. So we listen to when Linus loudly says no…
If the news were that Linus was ferret-lover, no one would care. But Linus knows a thing or two about managing the Git workflow of a pretty large project, and he created Git, so I'd give him some (a lot of) credit.
It blows my mind how one of the most influential software engineers, creator of linux and git, is reduced to "just a famous person like Tom Cruise who constantly negative" as if he's actually enjoying it or worse, that we shouldn't take what he has to share into consideration because he's used to express his viewpoint.
Maybe Torvalds is just as positive as he is negative and the whole reason why you think that he's someone who's "unsurprisingly negative" is because that's the content that everyone is passing around. If this was just another of his normal comments you wouldn't even see it posted.
Maybe Torvalds is just as positive as he is negative and the whole reason why you think that he's someone who's "unsurprisingly negative" is because that's the content that everyone is passing around. If this was just another of his normal comments you wouldn't even see it posted.
What Linus rightfully wants is the whole story right in the commit message of the merge.
I think GitHub purposely makes condensed commit messages for merges as a way to hook users to their web UI.