LWN: Comments on "An Interview With Linus Torvalds: Linux and Git (Tag1)"

Doesn't Git workflow have a "commit bit", too?

marcH — Sun, 09 May 2021 23:33:36 +0000

> But if the difference is more about the process than technical capability, then sure, I see why Torvalds can say that this doesn't exist in Git.

The huge technical difference is that the tool (git) is not tied to any particular process, it lets you do and organize in absolutely anyway you want. See also Karellen's very good answer below.

The technical magic is mentioned very briefly in the interview: "everything in git is an immutable object". https://www.google.com/search?q=+immutability+concurrency

It's the exact same "git clone" command to start:
- a "hostile" fork, or
- a "friendly" and temporary fork, or
- coding, or
- just explore!

First play with the source, then think about the politics later - if ever. Very much in line with the "no 5 years plan".

I used git the very first time as a ... subversion client! (git-svn) I wanted the freedom to branch and cherry-pick and amend and revert (for testing) and re-order commits _privately_. I wanted to "just do it" without wasting time discussing branch namespaces or other administrative topics for work in progress or short-live experiments. (Then I discovered magit that brings all this to yet another level). I'm always disappointed by developers who don't miss such freedom because the lack of "playground" makes it very difficult for them not to pollute the shared space.

An Interview With Linus Torvalds: Linux and Git (Tag1)

rgmoore — Sat, 01 May 2021 14:30:46 +0000

But that just pushes the question back a step: why did developers stick with Linus rather than chasing after the biggest userbase? I can think of three big reasons:

Technical leadership. People trust Linus to make the right technical decision the vast majority of the time, and to recognize his mistakes when he doesn't. I remember that when the Android people wanted to merge a bunch of their features (wakelocks, binder, etc.) back into mainline, Linus forced them to completely rethink their approach before he would merge their features. He didn't do that just by proclaiming he was the boss and they had to do things his way; he won a detailed technical argument about why their approach wasn't technically optimum and needed to be rewritten. This kind of thing has happened again and again, going back to the days of his famous argument with Andy Tanenbaum, to the point that people deeply trust that mainline will be developed in the technically correct direction.
Openness. Mainline Linux is developed out in the open where everyone can see what's going on. That gives developers the confidence they can understand what they're getting and that their code will be given a fair shake.
Neutrality. Linus has worked hard not to be employed by any of the big companies that depend on his software, which means people can count on him as a neutral arbiter. He isn't going to merge some half-baked idea because his employer needs it to ship on schedule or block something a competitor uses. Developers know their contributions will be judged on technical merit, not commercial concerns.

These are obviously intertwined to some extent. Linus would have a hard time maintaining his reputation for technical leadership if he weren't neutral or if Linux weren't developed in the open. It probably couldn't be developed in the open if he weren't neutral, since his employer might want him to keep stuff secret for commercial reasons. And his reputation for technical leadership gives him the chops to maintain the openness and neutrality.

An Interview With Linus Torvalds: Linux and Git (Tag1)

Wol — Sat, 01 May 2021 09:59:50 +0000

Probably because if they had split, Android might have had the larger USERBASE, but would have been of no interest to the DEVELOPERBASE.

And the whole point of using Linux is access to the large pool of developers.

Cheers,
Wol

An Interview With Linus Torvalds: Linux and Git (Tag1)

pabs — Sat, 01 May 2021 04:54:04 +0000

Allegedly Sony Xperia devices run close to mainline Linux versions, and can run mainline versions.

https://developer.sony.com/develop/open-devices/guides/ke...

An Interview With Linus Torvalds: Linux and Git (Tag1)

pizza — Sat, 01 May 2021 00:24:01 +0000

> In theory, the GPL could help out there, since it would give motivated users access to the code for their system, which they could theoretically merge themselves. In practice, it's a rare system that has enough motivated and technically competent users to make it happen.

That assumes the manufacturer ever provided the source code to begin with.

And even tier-one manufacturers (eg Google themselves) still ship some binary blobs.

An Interview With Linus Torvalds: Linux and Git (Tag1)

rgmoore — Fri, 30 Apr 2021 22:38:08 +0000

and that doesn't really happen with the mobile device forks (unless you choose to define "good parts" in a way that precisely excludes all the work done in those forks).

That's not necessarily a bad definition. The stuff that is most important to merge back are parts that are useful outside the fork, either because they touch some part of the core kernel or because they're drivers for hardware that exists outside the fork. For a lot of SOC systems, that doesn't amount to much. Most of what they're changing is hardware specific, and in many cases the hardware isn't used outside the one project.

It would be better for users if the manufacturer merged the hardware support back to mainline, since it would give the systems a prayer of being supported when the manufacturer gave up on them, but for fairly obvious reasons the manufacturers aren't too keen on spending the effort. In theory, the GPL could help out there, since it would give motivated users access to the code for their system, which they could theoretically merge themselves. In practice, it's a rare system that has enough motivated and technically competent users to make it happen.

An Interview With Linus Torvalds: Linux and Git (Tag1)

Wol — Fri, 30 Apr 2021 22:21:09 +0000

It's basically doing what all code, commercial and hobby does, leaving a trail of versions behind.

There is only ONE active development tree for Linux. Sure there are plenty of - I'll call them minor forks - around, but they are ALL dead ends, be it an LTS version, a chip-specific Android port, whatever.

But there is only ONE tree that is considered *a* master tree. And that is a social, not technical issue.

Cheers,
Wol

An Interview With Linus Torvalds: Linux and Git (Tag1)

rgmoore — Fri, 30 Apr 2021 22:09:39 +0000

Sure, but that permanent split hasn't happened. Instead, the Android developers see avoiding a split as sufficiently worthwhile that they've spent a lot of time getting their changes merged back into mainline Linux. It's obvious they are getting something very valuable by being connected to mainline Linux and avoiding fragmentation. Figuring out exactly what they're getting is a big part of understanding why Linux has avoided fragmentation.

An Interview With Linus Torvalds: Linux and Git (Tag1)

Sesse — Fri, 30 Apr 2021 10:46:12 +0000

That's not obviously so. Much of the merging back from Android in recent years has been because of a concern that Android and upstream Linux would otherwise de facto permanently split, with Android's kernel being the most relevant upstream.

An Interview With Linus Torvalds: Linux and Git (Tag1)

intgr — Fri, 30 Apr 2021 10:35:31 +0000

That's certainly true, but I think somewhat beside the point. Linus clearly acknowledges that forks happen all the time, but that's not the sort of fragmentation he is talking about.

These mobile device vendors still periodically update and restart from one of the mainline Linux releases, so in effect they still consider Torvalds's branch to be "the" Linux that they use, but they are on a different release cadence due to their custom patches. It's still bad, but it could be worse.

This is in contrast to the fragmentation of BSDs, where FreeBSD, OpenBSD, NetBSD and Darwin that will never merge again, compete for developers, and features need to be duplicated for each fork.

An Interview With Linus Torvalds: Linux and Git (Tag1)

excors — Fri, 30 Apr 2021 10:02:51 +0000

> I find it a bit odd; isn't Linux fragmented to death? E.g., how many mobile devices have been sold the last few years with anything even close to a mainline kernel?

I think there's a difference between forking and fragmentation. Maybe the device is running a device-specific fork of their chip vendor's fork of the Linaro LSK fork of the LTS fork of the mainline kernel; but there's still a clear hierarchy with Linus's mainline at the top. Any mainline commit will eventually filter through all the layers and end up on all new devices, even if it takes a few years. That seems significantly different to e.g. the BSD kernels, which (as far as I'm aware) have no such hierarchy and are each developed in parallel, apart from some common ancestors 2-3 decades ago. The latter sounds a lot more like fragmentation.

On the other hand, Linus says:

> So forking isn't a problem, as long as you can then merge back the good parts.

and that doesn't really happen with the mobile device forks (unless you choose to define "good parts" in a way that precisely excludes all the work done in those forks). There's little incentive to merge changes from the bottom back into mainline, because it's such a long chain of forks - each trying to provide some notion of 'stability' by updating infrequently - that by the time you've merged the patch upstream then waited for it to come down again, the chips are obsolete and out of production and the previously-manufactured devices are outside their support window and the code is now useless. So I'm not sure I'd call it fragmentation, but it's not the ideal kind of forking either.

An Interview With Linus Torvalds: Linux and Git (Tag1)

Sesse — Fri, 30 Apr 2021 08:29:17 +0000

I find it a bit odd; isn't Linux fragmented to death? E.g., how many mobile devices have been sold the last few years with anything even close to a mainline kernel?

Doesn't Git workflow have a "commit bit", too?

josh — Thu, 29 Apr 2021 21:17:10 +0000

Not necessarily "ignored"; some projects with a "commit bit mindset" do respond reasonably well to outside patches, but the response is almost always geared towards achieving commit access rather than reviewing a casual contribution from someone who doesn't *want* commit access.

You can run a project with git that still uses the "commit bit mindset", if you generally expect people to push directly or merge their own pull requests, and your review process is geared towards giving people commit access.

Doesn't Git workflow have a "commit bit", too?

wtarreau — Thu, 29 Apr 2021 18:07:31 +0000

It's not exactly the same. With central repositories, not having the commit bit really punishes the developer and encourages huge changesets. With git you can have 1 thousand local patches if you want and even never submit a pullreq if you're lazy, there's no punishment. However as soon as you think it would be better to get your code upstream (less maintenance nightmare, goodwill etc), it's normal that you have to pass through some layers of filtering / screening before your code is imposed to everyone.

In haproxy, a project I created 2 decades ago and still maintain, there are now a handful of people who can directly commit and even emit releases (we've run live tests on every single step to make sure the project resists to the bus effect on me). The selection of who has commit access is simply based on the fact that these persons produce a lot of commits and can quickly fix mistakes, so they're well accustomed to the details of how to optimally format commits etc. In exchange they help others get their code merged, reviewing and often adjusting a few minor issues for them. And you'll find that over time some natural associations appear with some contributors preferring to work with one of these persons because the relation is efficient. I find that this is a win-win. And I'm totally in favor of providing write access to more people, it's essentially that each commit induces a maintenance cost, and once this cost is offset by the time saved by the person being autonomous and making great commits, it's best if they commit themselves. Otherwise it's preferable that this cost can be slightly reduced by improving the commit message or adding a few info (or asking that the patch is reworked if the approach is not the right one).

So in the end it's not a matter of permission but of role. Hence it's not a commit bit, it has nothing technical but is entirely organizational.

Doesn't Git workflow have a "commit bit", too?

alexander.batischev — Thu, 29 Apr 2021 11:22:45 +0000

Ah, so the "commit bit mindset" isn't just the difference between those who can push into a certain repo and those who can't; it also implies that outside contributions are mostly ignored? I don't have a first-hand experience with this, but it reminds me of the ESR's "cathedral" model.

If so, then my point is invalid. I was thinking that the "commit bit mindset" is merely about the right to push, and since that's still present in Git, I thought Git has that too. But if the difference is more about the process than technical capability, then sure, I see why Torvalds can say that this doesn't exist in Git.

Doesn't Git workflow have a "commit bit", too?

Wol — Thu, 29 Apr 2021 11:03:09 +0000

A couple of projects I know (okay, they're small enough that all the core contributors know each other) seem to work almost on the basis that anyone can submit a pull request, and unless someone else nack's it, it gets merged into master by default.

But again, that's social organisation, git doesn't expect, require or enforce anything like that.

Cheers,
Wol

An Interview With Linus Torvalds: Linux and Git (Tag1)

shemminger — Thu, 29 Apr 2021 00:16:25 +0000

There already is Linus's comments on management.
"Everybody thinks managers make decisions, and that decision-making is important. The bigger and more painful the decision, the bigger the manager must be to make it. That’s very deep and obvious, but it’s not actually true."

But unfortunately, in my experience that runs completely counter to how most management operates.

Doesn't Git workflow have a "commit bit", too?

Karellen — Wed, 28 Apr 2021 22:34:34 +0000

Everyone has the "commit bit" on their own fork. Everyone can commit to their own fork with whatever rules they like, and everyone can set whatever rules they like about what patches they accept from someone else.

The way git works is that Linus' fork is not special technically. git doesn't have a concept of "upstream". You can link other "remote" repositories to yours, fetch their commits, and merge them into your fork as you see fit, but other people can add your repository as a remote to theirs (if you make it available to them) and fetch/merge from you as they wish too.

"Upstream" is a social/organisational decision. Linus' fork of Linux is special only because everyone decides that it is, not because of anything about the way git works. Linus chooses not to add your repo (or thousands of other potential contributors) as remotes and pull from them because you don't have a track record of trust for him, and that just doesn't scale well enough. You pull from him because you do trust him, and the organisation of helpers he's built around him. But you don't have to.

And yeah, lots of other orgs have a tree-like organisational structure for their git repositories, with a central/root repository that a few people are allowed to commit to, and which changes flow up to, and then back down from. github and their pull requests are built around this workflow quite strictly. But it's not inherent to git. You could have a highly connected network of core maintainers who maintain their own trees and all pull from each other. When it comes to making a release, if you do so based on an agreed-upon commit id, it doesn't matter which repo you tag/create the tarball from, as the same commit id is identical across all repos which contain it, so you don't necessarily need the concept of a central/root repo.

Doesn't Git workflow have a "commit bit", too?

josh — Wed, 28 Apr 2021 21:30:13 +0000

I think you can absolutely have a collaborating team of maintainers (like the graphics driver tree has) and still avoid the "commit bit" mindset.

I've seen the "commit bit" mindset in many projects. They don't support "drive-by" contributors, and even though sometimes maintainers will take the time to review patches, it's always with an eye towards deciding whether to give them the commit bit. So, the review process is optimized for "are you trusted enough to get the commit bit", which makes it hard to support casual contributors.

Doesn't Git workflow have a "commit bit", too?

alexander.batischev — Wed, 28 Apr 2021 20:54:28 +0000

> I always detested [the commit bit] model [of CVS/CVN], because it inevitably results in politics and the "clique" model of development, where some people are special and implicitly trusted. […] Again, in Git that kind of situation doesn't exist. Everybody is equal. Anybody can do a clone, do their own development, […]

…and then send a pull request to a person who can get those patches upstream? Isn't that the same as the "commit bit" model, just with better tooling? Now a person doing development has access to the entire history, and a fully-functional VCS, but they still have to go through "special" "implicitly trusted" people to merge the work. So Git simplified the technical side of things, but the process side — politics and the "clique" model of development — is still the same (or to be more precise, can be the same regardless of the VCS).

An Interview With Linus Torvalds: Linux and Git (Tag1)

wtarreau — Wed, 28 Apr 2021 17:22:10 +0000

Linus has excellent skills at understanding how people work, how to optimize their workflow, how to encourage them to engage more, how to show them some trust that will make them want to be more involved. And that makes him an excellent project manager.

Many times I found some parallels in the way I'm managing another project and some parts of the Linux' management (with many differences as well of course), and often I found myself replicating certain mistakes or bad directions that Linux suffered from and changing later for good. I never conscienciously copied him but I'm pretty sure I got naturally inspired by some process I was seeing working so well that the solution appeared totally obvious to me. So I tend to think that his management method is quite replicable and is not specific to the person at all (well you need a good temper, to forgive mistakes and to accept criticism but I think it's mandatory for any project manager anyway).

I sincerely hope that he will inspire youngsters who will eventually become managers in big companies, because his approach is highly scalable and quite rewarding for all parties involved.

I suspect that 10-20 years from now we'll say that he invented 3 things: Linux, Git, and the Linus-way-of-successfully-driving-a-project!

An Interview With Linus Torvalds: Linux and Git (Tag1)

smitty_one_each — Wed, 28 Apr 2021 17:19:47 +0000

> Linus should be a case study in business school textbooks

Indeed, he's done something quite a few others have not: transitioned to technical management.

In fact, there seems almost a total vacuum of discussion transitioning to tech management for coders amidst all of the business books.

An Interview With Linus Torvalds: Linux and Git (Tag1)

rsidd — Wed, 28 Apr 2021 16:05:06 +0000

It's a great interview, but I feel some of the other passages are even more important. Eg, this

That "anybody can maintain their own version" worried some people about the GPLv2, but I really think it's a strength, not a weakness. Somewhat unintuitively, I think it's actually what has caused Linux to avoid fragmenting: everybody can make their own fork of the project, and that's OK. In fact, that was one of the core design principles of "Git" - every clone of the repository is its own little fork, and people (and companies) forking off their own version is how all development really gets done.

and

And yes, I spend time on code reviews too, but honestly, by the time I get a pull request, generally the code in question should already have been reviewed by multiple people already. So while I still look at patches, I actually tend to look more at the explanations, and the history of how the patch came to me. And with the people I've worked the longest with, I don't do even that: they are the maintainers of their subsystem, I'm not there to micro-manage their work.

Linus should be a case study in business school textbooks (perhaps he is).