3 ms·

You assume that the creator of one of the.. if not the largest open source projects on the planet might not understand the issue at hand better than literally a

You assume that the creator of one of the.. if not the largest open source projects on the planet might not understand the issue at hand better than literally anyone? That seems arrogant. I imagine more thought & care went into git than you can fathom.

wpietri 5y ago
If "the issue at hand" is running a globe-spanning open-source project with hundreds of contributors, a bunch of targets, and a code base that goes back 30 years, sure, I'm happy to listen to Torvalds. if "the issue at hand" is the more typical modern work environment for devleopers, then no, I don't think he has much special insight. Indeed, the fact that he's wrangling something so large and important means he's unlikely to have the time and attention to devote a lot of thought to how best to serve a pretty different group of people. An obvious consequence of this is git's terrible interface. Its premise is "if you totally understand what Git is up to under the hood, the interface is great!" Fine for a small in-group of kernel developers whose lives are distributed patch sets, but terrible for the average developer. It has taken 15 years to get some reasonably named commands for common things like "restore a file". That's a great sign that we shouldn't listen to Torvalds on topics outside the realm of his admittedly impressive expertise.
geofft 5y ago
This isn't about "understanding the issue at hand," this is about UX development. Linux is, very intentionally, a piece of software which does not have "easy to understand for non-experts" in its design goals. You generally interface through Linux with system call wrappers provided by a libc (or another specialist library for other interfaces like libfuse or libnetfilter or whatever), not directly. Linus is, quite obviously, good at many things; it's silly to assume that means he's an expert at everything. Linus developed Git as a low-level tool. Linus put a lot of thought and care into getting the implementation details right, but intentionally did not build an easy-to-use interface. The Git command line that people use today ultimately derives from Cogito, a toolkit written by someone not Linus that sat on top of Git. Eventually Git (which Linus had long since handed off to someone else) adopted most of the conventions of Cogito and created a "porcelain"/"plumbing" split. If you think it was arrogant to develop Cogito, I suspect you disagree with Linus. Finally, Linus develops Linux with a very particular model, with e-mail-based patch reviews, merges from subsystem maintainers, etc. Most projects (even most open-source projects, but certainly almost all proprietary projects) do not work this way. The Linux kernel does not use a GitHub-style workflow for development, which is by far the most common way people outside the kernel community use Git. It may well be the case that a lot of thought was put into making Git work really well for Linus's use case but it does not match how other people do development.
- PaulDavisThe1st 5y ago
  The difference between the kernel development model, and some putative "typical other" development model merely changes which git commands/tools get used to handle getting stuff into a particular branch on the canonical repo. It has no impact on the underlying concepts that make git scale well, cover 100% and 100% remote cases equally well, and provide deep under-the-hood concepts that can be deployed in exceptional circumstances.
  - geofft 5y ago
    Correct, it has no impact on the internals of Git, which was my point. Git's internals are used by both the kernel development workflow and the GitHub-style workflow, and Linus designed it well. The conversation is about the user experience of using Git - its CLI design, etc. It is entirely about "merely" what commands are being used. TFA is about new Git commands, not about any changed internals. Or, in the case of Sourcetree, it's about not using any of "Linus's" interface to Git (which, again, wasn't written by Linus) but interacting with the same Git internals.
    - PaulDavisThe1st 5y ago
      I think the conversation is about whether or not the Sourcetree interface to git can be useful when carrying out tasks that involve, for example, filtering the reflog. If you have never done this before, and have only ever used git via the ST interface, switching to the CLI to get this done is going to be quite a shock. Maybe that's OK because realistically such tasks should be rare. But sometimes they are a critical task in development, and finding that the entire dev team is completely intimidated by it can be an issue.
ThrowawayR2 5y ago
Isn't that the "appeal to authority" fallacy? Mercurial demonstrates that you can have a VCS with less painful and frequent gotchas and certainly the grottiness of the git submodule mechanics, for example, doesn't show as much thought and care as one would hope.
- pofjer 5y ago
  How does Mercurial show it? I always found it very confusing to use all the times I tried it so I would need some context to understand your comment.

wpietri 5y ago

If "the issue at hand" is running a globe-spanning open-source project with hundreds of contributors, a bunch of targets, and a code base that goes back 30 years, sure, I'm happy to listen to Torvalds. if "the issue at hand" is the more typical modern work environment for devleopers, then no, I don't think he has much special insight. Indeed, the fact that he's wrangling something so large and important means he's unlikely to have the time and attention to devote a lot of thought to how best to serve a pretty different group of people. An obvious consequence of this is git's terrible interface. Its premise is "if you totally understand what Git is up to under the hood, the interface is great!" Fine for a small in-group of kernel developers whose lives are distributed patch sets, but terrible for the average developer. It has taken 15 years to get some reasonably named commands for common things like "restore a file". That's a great sign that we shouldn't listen to Torvalds on topics outside the realm of his admittedly impressive expertise.

geofft 5y ago

This isn't about "understanding the issue at hand," this is about UX development. Linux is, very intentionally, a piece of software which does not have "easy to understand for non-experts" in its design goals. You generally interface through Linux with system call wrappers provided by a libc (or another specialist library for other interfaces like libfuse or libnetfilter or whatever), not directly. Linus is, quite obviously, good at many things; it's silly to assume that means he's an expert at everything. Linus developed Git as a low-level tool. Linus put a lot of thought and care into getting the implementation details right, but intentionally did not build an easy-to-use interface. The Git command line that people use today ultimately derives from Cogito, a toolkit written by someone not Linus that sat on top of Git. Eventually Git (which Linus had long since handed off to someone else) adopted most of the conventions of Cogito and created a "porcelain"/"plumbing" split. If you think it was arrogant to develop Cogito, I suspect you disagree with Linus. Finally, Linus develops Linux with a very particular model, with e-mail-based patch reviews, merges from subsystem maintainers, etc. Most projects (even most open-source projects, but certainly almost all proprietary projects) do not work this way. The Linux kernel does not use a GitHub-style workflow for development, which is by far the most common way people outside the kernel community use Git. It may well be the case that a lot of thought was put into making Git work really well for Linus's use case but it does not match how other people do development.

PaulDavisThe1st 5y ago
The difference between the kernel development model, and some putative "typical other" development model merely changes which git commands/tools get used to handle getting stuff into a particular branch on the canonical repo. It has no impact on the underlying concepts that make git scale well, cover 100% and 100% remote cases equally well, and provide deep under-the-hood concepts that can be deployed in exceptional circumstances.
- geofft 5y ago
  Correct, it has no impact on the internals of Git, which was my point. Git's internals are used by both the kernel development workflow and the GitHub-style workflow, and Linus designed it well. The conversation is about the user experience of using Git - its CLI design, etc. It is entirely about "merely" what commands are being used. TFA is about new Git commands, not about any changed internals. Or, in the case of Sourcetree, it's about not using any of "Linus's" interface to Git (which, again, wasn't written by Linus) but interacting with the same Git internals.
  - PaulDavisThe1st 5y ago
    I think the conversation is about whether or not the Sourcetree interface to git can be useful when carrying out tasks that involve, for example, filtering the reflog. If you have never done this before, and have only ever used git via the ST interface, switching to the CLI to get this done is going to be quite a shock. Maybe that's OK because realistically such tasks should be rare. But sometimes they are a critical task in development, and finding that the entire dev team is completely intimidated by it can be an issue.

ThrowawayR2 5y ago

Isn't that the "appeal to authority" fallacy? Mercurial demonstrates that you can have a VCS with less painful and frequent gotchas and certainly the grottiness of the git submodule mechanics, for example, doesn't show as much thought and care as one would hope.

pofjer 5y ago
How does Mercurial show it? I always found it very confusing to use all the times I tried it so I would need some context to understand your comment.