Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Open Source Programming Linux

Torvalds Merges Support for Microsoft's NTFS File System, Complains GitHub 'Creates Absolutely Useless Garbage Merges' (zdnet.com) 77

Posted by EditorDavid from the Gitting-along dept.
"Linux creator Linus Torvalds has agreed to include Paragon Software's NTFS3 kernel driver, giving the Linux kernel 5.15 release improved support for Microsoft's NTFS file system..." reports ZDNet, adding that the driver "will make working with Windows' NTFS drives in Linux an easier task — ending decades of difficulties with Microsoft's proprietary file system that succeeded FAT...."

"But he also had some process and security lessons to offer developers about how to code submissions to the kernel should be made." "I notice that you have a GitHub merge commit in there," wrote Torvalds.

He continued: "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...GitHub is a perfectly fine hosting site, and it does a number of other things well too, but merges are not one of those things."

Torvalds' chief problem with it was that merges need "proper commit messages with information about [what] is being merged and *why* you merge something." He continued: "But it also means proper authorship and committer information etc. All of which GitHub entirely screws up."
TechRadar supplies some more context: One of the shortcomings Torvalds highlighted are GitHub's concise, factually correct, but functionally useless, commit messages. For instance, GitHub's commit message for Paragon's merge read "Merge branch 'torvalds:master' into master", which didn't impress Torvalds one bit...

Torvalds also had some pertinent security advice, perhaps useful in light of recent software supply chain cyberattacks that the Linux Foundation wants to address by improving supply chain integrity through tools that make it easier to sign software cryptographically. As Torvalds points out, this is particularly important for new contributors to the Linux kernel. "For GitHub accounts (or really, anything but kernel.org where I can just trust the account management), I really want the pull request to be a signed tag, not just a plain branch," Torvalds explains...

Torvalds suggests Paragon do future merges from the command-line.
This discussion has been archived. No new comments can be posted.

Torvalds Merges Support for Microsoft's NTFS File System, Complains GitHub 'Creates Absolutely Useless Garbage Merges' More

Torvalds Merges Support for Microsoft's NTFS File System, Complains GitHub 'Creates Absolutely Useless Garbage Merges'

Comments Filter:

  • > Torvalds suggests Paragon do future merges from the command-line.

    How will that help improve commit messages?

    • Re: Huh? (Score:5, Insightful)

      by hey00 ( 5046921 ) on Sunday September 12, 2021 @07:53AM (#61787787)

      If you merge yourself from the cli, you can pass any lotion you want to git, including a real commit message, and the commit author will be you. Whereas when you merge with github, you have nearly no control and end up with anonymous commit with useless comments.

      • Comment removed based on user account deletion

        • Re: Huh? (Score:5, Insightful)

          by evil_aaronm ( 671521 ) on Sunday September 12, 2021 @09:51AM (#61788027)

          Who cares. Get the code merged and move on.

          Said by someone who's obviously never worked on a large project that required any traceability.

          • Re: (Score:2)

            by Arethan ( 223197 )

            What manner of traceability are you suggesting is lost by github merges?

            When the PR submitter presses 'Squash and merge', you end up with all the PR commits squashed into a single commit, and the GitHub user that pressed the button is labeled as the author. This is the same level of authorship information that you're going to get out of using the `git` cli to perform the operations to create a squash-merge. The web UI even lets you edit the commit message that will be applied to the final commit -- it pre-f

            • Since that is not what Torvalds reports seeing, perhaps you need to educate the Paragon Software developers in how to do this properly.

            • Re: (Score:3)

              by Pimpy ( 143938 )

              Squash and merge is also an idiotic paradigm where bisectability over a sustained line of development of an out-of-tree branch is desirable. It's one thing if you're submitting something untested and spend a couple of commits trying to get it working before you're left with the polished version (which a lot of GitHub PRs seems to follow), and where you've developed and had something working for a lengthy period of time in which the changes you've been asked to make for upstreamability are just a few things

              • Re: (Score:2)

                by Arethan ( 223197 )

                Undoubtedly, the Github UI is a poor tool choice if you truly need octopus merge. I still don't understand the discontent with the platform though, given that it just as readily permits manual merges via the CLI.

                It seems more like this is a complaint against the Github-flow pull-request methodology. You don't have to use that method if it doesn't work for the type of project you're working upon. In my experience, it works pretty darn well for microservice development with a 2 week sprint cycle - the changes

                • Re: (Score:2)

                  by Pimpy ( 143938 )

                  Absolutely, the criticism was more directed at the kinds of commits/merges generated (and encouraged) by the GitHub workflow, rather than GitHub as a whole. There is certainly nothing stopping you from using the workflow-based merge for merging changes to specific branches and then doing the rest of the merging via the CLI, you'd just have to make sure that whoever is opening the PR knows not to squash/rebase in their own tree prior to opening a PR. That in itself, however, could be rather counterintuitive

        • Anybody who has worked on a big and/or important project cares. A lot. The whole point of change management is to know who made what change why, and to be able to check that years after the fact.

  • So GitLab then? (Score:5, Insightful)

    by SpzToid ( 869795 ) on Sunday September 12, 2021 @07:23AM (#61787739)
    Not only does GitLab offer vastly superior syntax-highlighting [wikipedia.org], but you can self-host on your own premises for free [gitlab.com], and write some pretty cool DevOps stuff [gitlab.com].

    Also, Microsoft doesn't own it, Microsoft won't try to merge it with Microsoft Teams in the future, etc.

    • Well they haven't because...wait for it...it's open source. Best way anyway since one is suppose to have a local copy to begin with regardless of what one's using is to sync back and forth with the remote repository.

    • What the hell do you guys think you need a hosting platform for your git projects, more so even a web-based one,
      when the whole point of git is that it's decentralized and there is no central repository and you don't need any crap frameworks or protocols for it?

      A file system, git, a good text editor, and some way of messaging around patches is all you need. Ideally by just mounting directories a la 9P, but e-mail or an IM tool with a CLI interface are fine too.

      My "hosting platform" is a file server. Anything

      • Gitlab (and hub) are more than just a git repo. It has some ci/cd, issue tracking, graph visualization, etc.

        It also acts as a cheap out free offsite backup and easy way to share your code with others.

        All that can be done in various other ways, of course. With gitlab doing all that easily, and the fact that it's open source and can be hosted as you want, i don't see much downsides, especially if you self host it or in my case, if you use one hosted by a trusted non profit.

        • Gitlab can be even hosted on a Raspberry Pi and work well. It also groks GPG signed commits, which are useful for defense in depth, especially when a Yubikey is used to sign commits.

          Of course, don't forget other Git servers like Gitea and GOGS. Those work well, but signed commits are quite useful to have, and Gitlab understands those.

      • Re: (Score:2)

        by tlhIngan ( 30335 )

        What the hell do you guys think you need a hosting platform for your git projects, more so even a web-based one,
        when the whole point of git is that it's decentralized and there is no central repository and you don't need any crap frameworks or protocols for it?

        A file system, git, a good text editor, and some way of messaging around patches is all you need. Ideally by just mounting directories a la 9P, but e-mail or an IM tool with a CLI interface are fine too.

        My "hosting platform" is a file server. Anything

    • I'm not a huge MS fan, having been a *nix-exclusive user for over 20 years, but MS has done a pretty good job with software they've bought like Skype. They haven't cancelled it, haven't forced users into their own products, etc.

      If google has bought it, it would have been cancelled years ago.

  • It's intrusive, baroque, self-serving, and fairly ridiculous. No wonder MS wanted to own it. S in PoS does not stand for software.

  • Don't fear the rebase (Score:3)

    by barlevg ( 2111272 ) on Sunday September 12, 2021 @08:29AM (#61787833)
    I worked on a large project for years where 90% of bugs were introduced during merge commits (and we didn't even let github do non-trivial merges). Things changed almost overnight after our product owner told us all to read this: https://hackernoon.com/dont-fe... [hackernoon.com] The rebase process doesn't make handling conflicts any easier--but what it DOES do is let you rewind to the exact commit where the borking occurred rather than having to sift through a massive reconciliation and nonlinear commit timelines.

    • Re:Don't fear the rebase (Score:5, Funny)

      by OzPeter ( 195038 ) on Sunday September 12, 2021 @08:52AM (#61787877)

      That’s one reason why Visual Sourcesafe was a superior product. By having file level locking of checked out code there are no merge commits, hence there can be no merge commit bugs! Eliminating an entire class of bugs is the smarter design.

      Ok. Ok, here’s the /S. And yes, I used VSS enough to know all about how bad it was. So no need to try and school me on it.

      • Re: (Score:2)

        by znrt ( 2424692 )

        what a hill to die on ...

        you're actually right, but in most modern environments source file locking is simply not an option and i have a car analogy to prove it: if you limit speed to 4km/h you end car accidents forever, completely. that's thousands of premature deaths avoided daily. except that idea is not going to float for some reason.

      • There is a better way: have the owner of the code review and merge the changes.
        Since there is a single owner, it serializes naturally.

    • And here I thought rebasing onto the main dev branch before merging wad standard practice.

      Rebasing creates exactly the same conflicts as merging, so instead of doing the merge and having to fix the conflict in the merge commit, or have gitlab/hub fuck your history of you try to merge from the web interface, there is no reason not to rebase and fix them on the branch.

      And the second advantage is that if your branch has several commits and you merge without rebase, then those individual commits lose relevance

  • Microsoft support syndrome? (Score:5, Funny)

    by BAReFO0t ( 6240524 ) on Sunday September 12, 2021 @08:53AM (#61787881)

    concise, factually correct, but functionally useless, commit messages

    Sounds like any answer you get from Microsoft support.

    As in this joke:

    A helicopter with a pilot and a single passenger was flying around above Seattle when a malfunction disabled all of the aircraft's navigation and communications equipment.
    Due to the darkness and haze, the pilot could not determine the helicopter's position and course to get back to the airport.
    The pilot saw a tall building with lights on and flew toward it, the pilot had the passenger draw a handwritten sign reading, "WHERE AM I?", and hold it up for the building's occupants to see.
    People in the building quickly responded to the aircraft, drew a large sign, and held it in a building window.
    Their sign said, "YOU ARE IN A HELICOPTER."
    The pilot smiled, waved, looked at his map, determined the course to steer to SEATAC airport, and landed safely.
    After they were on the ground, the passenger asked the pilot how the "YOU ARE IN A HELICOPTER" sign helped determine their position.
    The pilot responded, "I knew that had to be the Microsoft support building, they gave me a technically correct but entirely useless answer."

    • Re: (Score:1)

      by SpzToid ( 869795 )
      How many Microsoft engineers does it take to screw in a light bulb?

      No Microsoft engineers are required to screw in a light bulb, nor is receiving support from Microsoft an option, because Microsoft will just declare Darkness to be the new Standard.

      Of course this joke is older than Google and has aged a bit, but still.

  • If Microsoft really believed on openness (Score:3)

    by jmccue ( 834797 ) on Sunday September 12, 2021 @08:55AM (#61787889) Homepage

    If Microsoft really believed on "open source", they would create the pull request and merge their code into Linux

    To me, all this proves is they have an agenda.

    • Re:If Microsoft really believed on openness (Score:5, Insightful)

      by Anonymous Coward on Sunday September 12, 2021 @10:15AM (#61788061)

      MS's NTFS code is for *Windows*. How well do you think that would merge into the Linux kernel? /s

      The Paragon driver is, in effect, the MS blessed Linux NTFS driver. 'Old' MS would no doubt have 'had a word' with Paragon (who got unspecified help from MS with their driver, likely on the condition it was paid for, with MS getting a royalty, and thus not kernel merged).

      'New' MS is perfectly OK with this and presumably must have released Paragon from any such obligations, otherwise they wouldn't be able to do this.

      It appears that MS didn't actually patent bits of NTFS (unlike FAT32 and exFAT, whose patents eventually respectively expired or were opened for Linux royalty free use via the OIN). So including this driver doesn't bring patent risks (if there were patents, MS would have OIN'd them, or this would not be happening).

      It's a great advance for anyone who needs to share data between Linux and Windows via NTFS (e.g. dual-boot setup), with a 4x improvement in performance over the NTFS-3g FUSE driver.

      And no, MS has not changed from 'evil' to 'good', it's just that they are not bothered about trying to sabotage or limit Linux anymore, since that serves no purpose for them. Given that with WSL2 'real Linux' is supported from within Windows, and given their Azure cloud business profits from Linux adding extra interoperability features to Linux is presumably a positive for them.

      Linux people: MS is *no longer the enemy*. MS *makes money* from Linux (although we still need to be vigilant, of course for MS attempts to 'steer' Linux - but other Linuxy companies like IBM and Oracle act as counterweights).

      • Re:If Microsoft really believed on openness (Score:5, Interesting)

        by ctilsie242 ( 4841247 ) on Sunday September 12, 2021 @02:22PM (#61788749)

        As an iconoclast, I wish NTFS were the same version that is what MS is using for Windows 11 and Windows Server 2021. That, and the ability to use it as an option for a Linux distribution root filesystem.

        It sounds crazy, but even though NTFS is not as flashy as ZFS or others, it is a filesystem that has stood the test of time, and not just have had bugs hammered out, but a lot of feature additions, be it deduplication, compression, file encryption, ACLs, alternate data streams, snapshots, and other items. NTFS can't detect bit rot, but it can be snapshotted for backups relatively easily, and because of how permissions work with it, it is easy to add UNIX style perms onto directories in that environment.

        For external drives, it will be extremely useful. Right now, we only have ExFAT as a common filesystem between Macs, Linux, and Windows. Moving to NTFS gives a lot of data protection features like journaling, deduplication, and other items.

        The only thing NTFS doesn't really have is bitrot protection with checksums.

        • Right now, we only have ExFAT as a common filesystem between Macs, Linux, and Windows

          UDF also works. But no one gets royalties from that. But it does work on all operating systems.

  • Ah, the irony of Linus complaining about git. The rest of us has to use this unnecessarily complex, confusing and completely unnecessary SCM which in no way is suitable for a team of 5 or 500 inside of a company. 8 years ago, we had multiple usable SCM systems that were easy to use. Their merge algorithms were clever and suitable for application level use or system level use. You only needed to know about 3 or 4 commands and they were all simple. The worst UI of any of the SCM's was P4 and that was onl

    • Git's features are designed to deal with the complexities of a large open source project. If you are not working on one of those, then Git isn't suitable and you are only using it because Linus does. The merge algorithms of Git are designed for a a system's level project. Meaning the merges almost never work by design. Because you don't want subtle bugs sneaking into your kernel code. However, that webservice you write has none of those complexities and you just end up having to needlessly handle merges yourself if someone else decides to cherry pick something. Seriously, if he wants Git to be useful to him, he needs to quit pushing it on app level devs. He needs to tell the truth and say, "Git is only for large OS projects and if you use it for your professional team, you are probably making a mistake". Oh, and Web PR Management existed before Git, your company just didn't license the Web GUI.

      I sure wish you would show some examples because some of this is hard to grasp but just the same I do think you are right. I myself would put git in a conceptual sense right up there with gcc. I know, I know "whatever".., but I believe in convergence even if all you achieve is transparency, I just has to be that way.

    • Re: (Score:2)

      by ledow ( 319597 )

      Git was invented to be suitable for kernel development. Everything else is a third-party bolt-on. That people see the value and sell it for billions as a website is their problem.

      "If you are not working on one of those, then Git isn't suitable"

      Correct. So why are people using it for those things?

      Choosing an unsuitable tool and then blaming the tool is a bit disingenous.

      You know, my screwdriver is useless for knocking in nails! Bad screwdriver! They should fix it!

  • I hate GitHub. Google Code was much better for small projects.

  • is this the merge you guys said was "NFS"?

Slashdot Top Deals

Let the machine do the dirty work. -- "Elements of Programming Style", Kernighan and Ritchie

Close