back to article GitHub merges 'useless garbage' says Linus Torvalds as new NTFS support added to Linux kernel 5.15

Linus Torvalds will pull Paragon Software's NTFS driver into the 5.15 kernel source – but he complained about the use of a GitHub merge in the submission, saying that GitHub "creates absolutely useless garbage merges." Early last month Torvalds gave Paragon Software a nudge that it really should submit a pull request – an …

  1. Filippo Silver badge

    In fairness, the git command-line interface is... not exactly easy to learn. Of course, this is a very important project, and needs to be done properly, but I feel their pain.

    https://xkcd.com/1597/

    1. Yet Another Anonymous coward Silver badge

      Git errors unclear?

      What's unclear about 'foxtrot merges not allowed on forward laterals when Mortimer's rule is in use and the user isn't in nidd'?

      1. Anonymous Coward
        Anonymous Coward

        Samantha has to step out now

        Some git is trying to pull and she's been requested to submit.

        1. This post has been deleted by its author

      2. bazza Silver badge

        Come on then, let's give it a go with those rules

        I'll start.

        Green Park

        (note to all USAians:- this is a game, the rules of which become self evident through the playing of it. You'll need a London Underground map and all will be clear).

        1. AndrewB57

          Re: Come on then, let's give it a go with those rules

          Ha

          Kensal Green

          Also this will be helpful for The Cousins

          https://traintimes.org.uk/map/tube/?fbclid=IwAR2bvGuMNrLh9sfHnIP0HsEc8JhAhSj7ywwU1Z4c-7t2H_nMPom1BsWW82s

          1. Yet Another Anonymous coward Silver badge

            Re: Come on then, let's give it a go with those rules

            Is it true that being able to play Mornington Crescent is the new Turing test for AIs?

        2. Brian Morrison

          Re: Come on then, let's give it a go with those rules

          Clear? No, it really won't. Unless your surname is Trellis.

          1. Anonymous Coward
            Anonymous Coward

            Re: Come on then, let's give it a go with those rules

            No, my name is actually Mrs "Trellis-of-North-Wales"

            It is an unusual surname, especially here in Scotland, due to a series of inter-marriages among the Norths, Waleses and the ancient Trellis-Of family

      3. Hawkeye Pierce
        Joke

        Good to see I'm not the only one for whom Mornington Crescent immediately sprang to mind...

        Cockfosters.

        1. katrinab Silver badge
          Trollface

          Stations with NSFW substrings in them can't be visited before the 9pm watershed.

          You have been diverted to East Acton station for Wormwood Scrubs Prison.

          1. Wenlocke

            Hammersmith.

            1. Anonymous Coward
              Anonymous Coward

              Edgeware Road

              1. Allonymous Coward

                Are we playing the East Indian variation? If so, I think you’ll find stations that begin with a vowel aren’t allowed on days that begin with “T”. Unless you’re in transit to a mainline connection of course.

                With that in mind, I raise you: Bank.

                1. Anonymous Coward
                  Anonymous Coward

                  Hmm, that's on the diagonal, but not yet in nip. So logically, that means

                  Shepards Bush

                  1. katrinab Silver badge
                    Trollface

                    Euston - it is on a mainline, and can be reached from Shepherd's Bush via the Overground, so complies with the East Indian variant rules.

                    1. Brian Morrison
                      1. bazza Silver badge

                        Mornington Crescent?

                        I may have side slipped too much, I'll accept a referee's judgement...

                      2. Yet Another Anonymous coward Silver badge

                        >Rules?

                        The basic rules themselves are so simple as to hardly need stating.

                        But a player will want to familiarise themselves with the minutiae of the game

                    2. Allonymous Coward

                      <looks over top of glasses>

                      Hmm. I see you’re familiar with the game. Well played. Well played indeed.

                      Of course, Mornington Crescent is only one stop away on the Northern Line. But if we’re on the Charing Cross branch and there’s no step-free access I’m not sure that’s a legal move. I may have to defer to the TMO on this one.

                      1. bazza Silver badge

                        No, you're right of course. I'll try another move, try to be a bit less in nidd.

                        Er, how about Aldgate East, using District Line rules?

                        1. M. Poolman

                          Er, how about Aldgate East, using District Line rules?

                          I think that is only valid if the Gryncham-Thrib exceptions to Huffington-Bates variant is in play.

                          1. bazza Silver badge

                            Re: Er, how about Aldgate East, using District Line rules?

                            Oh blast, I'm really getting deep into nidd now. I'll play safe. Kings Cross.

                            1. Yet Another Anonymous coward Silver badge

                              Re: Er, how about Aldgate East, using District Line rules?

                              Isn't another mainline station a reverse?

                              What about St Pancras 'international'

                              1. bazza Silver badge

                                Re: Er, how about Aldgate East, using District Line rules?

                                Oooh a risky move, leaves open escape routes to both Luton and Paris. Brave play!

                                1. Yet Another Anonymous coward Silver badge

                                  Re: Er, how about Aldgate East, using District Line rules?

                                  Unfortunately with the Cameron-Johnson Discombobulation in place Paris is out, will have to be Luton

                                  1. Yet Another Anonymous coward Silver badge

                                    Re: Er, how about Aldgate East, using District Line rules?

                                    Should also point out that only us Yorkshire players are in Nidd (it keeps the ferrets cool)

                                    However, southerners with a particularly weak grasp of the game may find themselves in Knip.

    2. Warm Braw Silver badge

      the git command-line interface is... not exactly easy to learn

      If only we could identify who was responsible...

      However, there's quite a serious point here. Given the shortage of Linux maintainers it would presumably help if otherwise competent developers aren't being avoidably tripped up.

    3. Vometia has insomnia. Again.

      I first encountered git thanks to FreeBSD migrating away from svn shortly after I'd endured yet another fight with systemd; and unfortunately felt quite a sense of deja vu. I've scripted what I need it to do and feel disinclined to poke it with a stick.

      1. sev.monster Bronze badge

        It's unfortunate that the git "porcelain" commands we use on a daily basis are essentially scripts on top of the "plumbing" commands. Git's needless complexity via multiple ways to accomplish varieties of tasks and ift esoteric command names (git symbolic-ref? A sculpture of a football referee?) does it no favors.

    4. MacroRodent Silver badge
      FAIL

      xkcd

      That xkcd captures very well my git experience. Initially I raged at it, but have now grown numb and apathetic. I just have a file "git-tricks.txt" from which copy_paste commands, and if that does not help, rm -rf and git clone to start over...

      Add Gerrit to that for extra pain...

      1. Def Silver badge

        Re: xkcd

        I suffer git at work, but use Perforce at home for my own projects. I will never let git anywhere near my code.

      2. Jay 2

        Re: xkcd

        Where I am uses gitlab, so I have a snippet with such handy git commands I can copy/paste where needs be. Esp when cleaning up after a merge.

    5. chuBb. Silver badge

      Id say the GIT CLI is no harder to learn than any other CLI, what makes git tricky to understand is its choice of nomenclature which activly fights the intent of the command.

      While there may well be historical reasons for "pull request", but lets face it the vast vast majority of git users use a hosted repository, so any attempts at names that allow the ambiguity of the distributed aspect of git is pointless these day, it would be much better named "Merge Request" or "Merge Review" in my opinion, as that is effectively how its always been used in any project I've been involved in.

      Rebase is another crap name used by GIT, despite having used git for the best part of 20 years i would struggle to explain its function in detail without some form of reference, "magic reset update merge keep working copy changes" command might be better as at least it conveys some of what rebase does, even if it would be a bugger to type on cli (but thats what the tab key is for in your terminal of choice)

      1. Brewster's Angle Grinder Silver badge

        A bit like the XKCD, somebody has to link to rebase considered harmful.

        1. bombastic bob Silver badge
          Unhappy

          I did a rebase once. It was stressful. I think I triple-checked every command. Had no choice. I was working on an automated e-mailer shell script [sends analysis files from an SQL database within a zip file attached to an automated e-mail to several people via a crontab entry using shell and Perl] and forgot to sanitize the script first. Ooops. The script, I must say, is brilliant. My mistake unfortunately ruined my moment of triumph.

          As many of us probably already know, ALL git history is available for anyone with access to the repo. So if you accidentally commit something you should not, a key, a token, a pass phrase, peoples e-mail addresses, whatever it might be, if you do NOT rebase to a point before that commit, it will be visible FOREVER, even if you do a subsequent edit to remove it.

          (So at least the option to do a 'rebase' was there to fix it)

          1. FIA Silver badge

            As many of us probably already know, ALL git history is available for anyone with access to the repo. So if you accidentally commit something you should not, a key, a token, a pass phrase, peoples e-mail addresses, whatever it might be, if you do NOT rebase to a point before that commit, it will be visible FOREVER, even if you do a subsequent edit to remove it.

            It’s possible to rewrite git history. Like most of git it’s some magical shell incantation, but you can do a regex search/replace on the entire history. I’ve done this before to remove public email addresses from repos before pushing to GitHub.

            You do need to ensure everyone gets the modified repo though so it may not be a trivial task.

        2. CrackedNoggin Bronze badge

          > "What is the fastest path to solid code? Is it to continue staring at your private branch to seek out every last bug, or is it to publish it as-is, whereupon the many eyeballs will immediately see that last stupid error ..."

          We'll see what MS has to say about that ... cue Windows 11.

        3. sev.monster Bronze badge
          Angel

          These last few hours, i have been digging through the treasure trove of articles on the Fossil website. I've never used anything but SVN and Git... I didn't know there were less turbulant waters out there.

          Thank you for converting me to Fossil, St. Grinder.

      2. chuBb. Silver badge

        And in gits defense, at least its not source safe....

        1. Anonymous Coward
          Anonymous Coward

          At least it's not starteam... Though TBH starteam has a decent history view just a real pity at how dated the rest of it is even with all the updates. The history info is in git just not so easy to use.

          1. anothercynic Silver badge

            STARTEAM? *ARGHHH*

            We migrated away from that to Perforce.

      3. Must contain letters

        Only 20 years?

        How time flies, though I recall git was spawned in 2005?

      4. bombastic bob Silver badge
        Devil

        what makes git tricky to understand is its choice of nomenclature

        true. I had to re-train my thinking a bit to familiarize myself with that the @#$% they actually MEANT by "that" (whatever 'that' is for the current context). It did not take long before I "got it".

        I've used P4, cvs, svn, and git. I prefer svn for my own things, but git's ok for public and work-related projects. I've also (*cough*) experienced "Source Safe" back in the day and I *ahem* "perceive myself to have been involuntarily violated and become dirty" because of it...

      5. jarfil

        Rebase = "move a bunch of commits to start at another base commit"

        The name is fully descriptive if you think of it as a Christmas tree: change the base of the tree, re-base...

        1. bazza Silver badge

          So, why not "re-trunk" or "graft" then?

          1. richardcox13

            Re-trunk would imply there is a special trunk branch. but there isn't. In git all branches are equal. (Processes for humans might define some to be more special, but that is not part of git itself.)

            I learnt git by just using git from the command line for a project I was starting, and just took the learning time. Having rather different terminology overall helped, because it reminded me the underlying conceptual model is different.

            Also, spending time understanding that model really helped. a D-VCS is very different to a centralised one, trying to use git as if it were a centralised VCS is doomed to repeatedly being caught out by the differences.

            PS. Barons Court (applying Mont's bypass, and you're in Nidd).

        2. chuBb. Silver badge

          I would suggest transplant or couple are better synonyms than rebase to describe its functionality

      6. Robert Grant Silver badge

        Id say the GIT CLI is no harder to learn than any other CLI, what makes git tricky to understand is its choice of nomenclature which activly fights the intent of the command.

        While there may well be historical reasons for "pull request", but lets face it the vast vast majority of git users use a hosted repository, so any attempts at names that allow the ambiguity of the distributed aspect of git is pointless these day, it would be much better named "Merge Request" or "Merge Review" in my opinion, as that is effectively how its always been used in any project I've been involved in.

        To give you just a little history, then: the "Pull Request" to which you refer is an invention of one of those hosted repositories, GitHub, and not part of core Git. GitLab calls them Merge Requests.

        1. chuBb. Silver badge

          Indeed, but as linus himself uses the term pr I think its safe to say the less clear term won

          1. Robert Grant Silver badge

            That's because PR means something else in core Git. Either way, you can't blame Git for not being friendly enough to hosted services' users, when the confusing term was made and is only used by one of those services.

            1. chuBb. Silver badge

              I don't blame git for not being friendly enough for hosted services (as you mentioned the better hosted providers have taken steps to help their users who just want version control, SVN/Perforce would fit them better but GIT won), i do blame GIT for being needlessly obtuse at times though.

              Frankly its one of the few big FOSS apps that clings to the old 90's RTFM/man git/why havn't you read and memorised thousands of emails in the mailing list response to basic questions. When the answer is the docs suck for most humans and you need to spend a lot more time on the technical authorship and supporting documentation as IT IS a feature of the software, rather than responding with a passive aggressive i'm smarter than you, and i wont help response....

      7. drankinatty

        Captured to a "T"

        Could not have said it better. The CLI for git is a fantastic tool, but just like any advanced piece of software, you have to make friends with it first. You wouldn't sit down to write something in C having only a passing knowledge of the language, or you wouldn't write a Bind config or zone file without significant effort to learn the lingo of the Berkeley DNS named server.

        The git nomenclature does suck! Not that it is bad, but that it is completely non-intuitive for someone who may otherwise be very skilled and fluent in a number of other projects that are now hosted on Github. The git command line is its own little language.

        To the git project's credit there are very good tutorials to help you make friends with it, but the downside is they are some 30 page tutorials that are not geared to answer "the top 10 things you normally need to know to use git". (there are some of those floating around though)

        So there is learning involved (the choice of nomenclature just makes things that much more uncomfortable). However, the choice of nomenclature does begin to make more sense the more you become steeped in git. (but that doesn't take the sting out of it the first time you sit down to use it...)

    6. vtcodger Silver badge

      Thanks to All

      Thank you folks. All of you. I'd always assumed that my inability to grok git was due to my stupidity and perhaps a bit to a loss of mental accuity as I slog through my eighth decade on this planet. But you make it appear that perhaps part of the problem that git really is as obtuse and confusing as it seems to me. Thanks ever so much.

      1. M. Poolman
        Pint

        Re: Thanks to All

        Thanks, old bean, have one on me! I thought it was only me as well; perhaps there is a case of the emperor's new clothes here? GIT does have some attractive features, but it sure as hell is a PITA to learn.

      2. -tim

        Re: Thanks to All

        As far as the confusing and obtuse parts of git, I wonder if that is related to how git has some verbs where the subjects don't quite follow normal UK/USA speech patterns. It is like a Finn or a Swede who asks "I'm a bit low on cash, can you borrow me $20?" It is hard to parse because the direction of the word "borrow" seems backwards to most people. I've heard that enough times I should figure out the proper way to ask for my money back.

    7. bombastic bob Silver badge
      Meh

      the git command-line interface is... not exactly easy to learn.

      I dispute the accuracy of your opinion. example follows...

      From the article: you should never ever use the github interfaces to merge anything

      When I read that part, I knew EXACTLY why Linus would say this. For a raw pull request (i.e. submitting your dev branch's differences from the official repo) the github inteface works very well. For actual editing and stuff, no.

      Therefore you should just do all of your merges and any additional edits using a decent local merge tool (maybe 'meld'?) between your local working copy and the dev branch on github, after you do a 'git pull' on your local copy of the dev branch so you know that what you're comparing to for your merge is at least CLOSE to what you'll be doing the pull request for (assuming that no major edits in the official branch affect the pull request).

      Then use 'git commit' followed by 'git push' to your dev branch, and then do the pull request.

      You really only need to memorize and master a few git commands:

      git status

      git pull

      git push

      git commit

      git add

      git rm

      the rest of the commands can be looked up in the docs "whenever", as needed.

      NOT that hard. seriously NOT. But yeah you need a token. And I solved that.

      If you search for it on github, I wrote a simple program that lets you use a pass phrase to decrypt an encrypted file and put its contents in the clipboard (for X11 systems though). In short, you would encrypt the github issued 'password' token in a file, and then run the utility from a command shell (say 'bash') and enter your pass phrase, and the github token will be on the clipboard. Then, when you do 'git push' and git prompts for user/pass, you type in the user and paste the token when it prompts for password. This is due to github's recent policy change regarding pass phrases and git command line, and the method I use can be put on computers you do not own (like customer machines) as needed to access github repos without revealing your token.

      1. AddieM

        That would probably be enough commands for my personal projects, when it's only me making changes, although I'd probably add `git diff` as well. For work, when my colleagues might inconsiderately change files that I'm working on too, or I need to backport fixes to a release branch, then `git rebase` and `git cherry-pick` are essential too.

    8. Dan 55 Silver badge
      Devil

      If it's an important project and needs to be done properly, use subversion (and it's not as if I like that very much either). If it isn't, go ahead and let git play the shell game with your changes.

      To this day I have no idea why git is supposedly so fantastic if it gets absolutely everything round its neck when committing and reverting. After messing about with it too much, I finally categorised it under "pointless stuff I have no time for".

      1. skierpage

        Git is a DISTRIBUTED version control system. The distributed part makes it fundamentally hard! The arcane commands permit, for example, someone who has spent months developing a feature on their own local branch to painstakingly adapt it so that it appears to be a sensible sequence of changes to the latest code in the main repository. That's exactly what Linus requires, not a commit history of "Got it working", "Grab latest kernel" (dozens of changes that have already been made in the main repository), "Whew, got it working again", repeated.

        Two developers I respect told me the way to really understand git is to read its source code. Otherwise as commenters here have said you rely on lists of commands that mostly work until you develop a feature on a long-lived branch.

        1. Dan 55 Silver badge

          I know it's distributed, but even when it's not really (i.e. I know only I'm using the branch and I'm up to date), and I want to do something like delete a few files, rename a few others, and add new files in the same revision, it does things like deciding some deleted files have been renamed to a new file because their content is similar. Apparently the most reliable way is committing the deleted files in one revision, then committing the renamed files in another revision, then committing new files in a third revision. So much for Linus' nice clean commit history.

          Even reverting one single file becomes an odyssey in itself which could take other files with it.

          If really have to read git's source code to understand how it works then that's a failure. It should have a handful of understandable commands with predictable outcomes.

          And as for git's supposed raison d'etre, didn't Linus just say GitHub merges were useless garbage anyway? What task does GitHub call to perform the merge?

  2. Howard Sway Silver badge

    Note that the git request-pull command is different from the GitHub pull request feature

    Of course! One is requesting a pull and the other is pulling a request : the second one is not the request of a pull, nor is the first the pull of a request, which should be obvious to anyone. However, if you disagree you can always submit a pull request to request an update to request-pull.

    1. Starkoman
      Facepalm

      Re: Note that the git request-pull command is different from the GitHub pull request feature

      “Clear as an unmuddied lake, Mr. Deltoid”, said Alex.

  3. Anonymous Coward
    Anonymous Coward

    All very fine.....love it when the anoraks get excited about stuff like "git"........

    ......but my problem is MUCH simpler.........

    *

    Has the next kernel update from RedHat actually been tested by anyone? I'm currently FED UP with having to worry about whether 5.13.13 might be a problem, since my (multiple) machines are all up to date on 5.13.12. It wouldn't be so bad......except for the treadmill of having to deal with this EVERY WEEK!!!

    *

    From 1982 to 1985 (i.e. more than three years), CP/M-80 was stable at version 2.2.

    *

    From 1986 to 1992 (i.e. more than five years), MS-DOS was stable at version 3.3.

    *

    From 2003 to 2005 (i.e. more than two years), RedHat version 9 (retail) was stable.

    *

    Today.......EVERY WEEK THERE'S AN UPDATE.................................................

    *

    Am I missing anything here?

    *

    Signed: NotAnArorak (just an ordinary person)

    1. Adrian 4 Silver badge

      Re: All very fine.....love it when the anoraks get excited about stuff like "git"........

      If you don't want constant updates the solution is simple : don't follow a dev track which is there specifically to allow frequent, poorly tested updates.

      From your examples, I would suggest you want the releases marked 'LTS' or long-term-stable.

      Try Debian. they're exceptionally careful about what goes in, and you won't suffer much harm if you miss out every other release for even longer life.

    2. Pascal Monett Silver badge

      Re: From 1982 to 1992 there was no Internet to speak of*

      So yeah, things were a lot more stable when the only way to hack a computer was to sit in front of it.

      * - yeah, I know, the Internet existed in 1992, but the number of people who actually had access to it was pathetic and the hacking culture was yet to be invented on the scale it has become today

      1. msobkow Bronze badge

        Re: From 1982 to 1992 there was no Internet to speak of*

        *LOL*

        I love it when the kids claim they created some "new culture" that has actually been around since the Phone Phreaks of the 1970s-80s. Hacker "culture" most certainly did not spring into being with the internet.

        1. Anonymous Coward
          Anonymous Coward

          Re: From 1982 to 1992 there was no Internet to speak of*

          To reinforce your point, you have to go back a lot further than the 1970s for phone hacking. My father was doing it in the late 1950s and the techniques he was using had been viable since before World War 2...

          1. Pascal Monett Silver badge

            Well yes, but phreaking gave one person one international call.

            It did not bring down thousands of data centers.

            The scale is not the same.

        2. Robert Grant Silver badge

          Re: From 1982 to 1992 there was no Internet to speak of*

          > on the scale it has become today

    3. damiandixon

      Re: All very fine.....love it when the anoraks get excited about stuff like "git"........

      Could always try ArchLinux... Tried it for the first time last month took me back to last century installing Linux.

    4. Dazed and Confused

      Re: All very fine.....love it when the anoraks get excited about stuff like "git"........

      Well that's what they have RHEL for. All versions of RHEL 7.X use 3.10.0 and all versions of RHEL 8.X use 4.18.0. They then offer fixes into those releases, typically every couple of months.

    5. Brian Morrison

      Re: All very fine.....love it when the anoraks get excited about stuff like "git"........

      5.13.13? And you have 5.13.12?

      Oi vey... s'pah! You're out of date, you need 5.13.14 if you want your bluetooth earbuds to work.

      You will need 5.14.1 or later if you also expect your Realtek USB Bluetooth dongle to work without having to faff about with renames and soft links in /lib/firmware/rtl_bt/

      And that's only the first half of this week!

  4. Pascal Monett Silver badge

    "I've never actually required that"

    May I humbly submit to the overlord of the One True OS Kernel that it might, just maybe, be an idea to think about doing so, given all the grief that is currently being caused by state-level groups who are actively trying to subvert entire supply chains ?

    Not that I would be so bold as to tell The Great One how to manage his pet project that powers the Internet, worldwide communications, space probes and practically everything that is not a desktop PC or a laptop.

    But it might be worth considering . . .

    1. doublelayer Silver badge

      Re: "I've never actually required that"

      Because anybody can create a GPG key, and a lot of changes are made by people who don't have a company behind them. A GPG key linked in some verifiable way to Paragon could be trackable, but a GPG key linked to an individual could lead to a real one as well as to a fake one. And they could also be stolen, so even if you know that someone is definitely legitimate rather than has submitted legitimate code thus far because they'll be inserting the dodgy stuff later, you don't know for a certainty that it's them submitting that code.

      If you know everybody involved, having a system where you verify who the contributor is as your primary trust system can work. If you let everyone on the planet submit code, then that approach has reduced utility. It doesn't make it useless, but don't rely on it to save you from any particular situation.

  5. Anonymous Coward
    Anonymous Coward

    This feels like the kind of thing that'll have an 'accidental' *uid = 0 buried somewhere in it. Go over it with a fine tooth comb, linus

    1. oiseau Silver badge
      Facepalm

      ... feels like the kind of thing that'll have an 'accidental' *uid = 0 buried somewhere in it.

      Finally. 8^/

      I've been thinking that is what will eventually happen (sooner than later) ever since it was announced.

      I really see no need for it, none whatsoever.

      Not in or within the Linux ecosystem.

      I've been using Linux for over well 10 years now and I can't recall the last time I had to look into a NTFS format drive.

      Go over it with a fine tooth comb, linus ...

      Indeed ...

      Better yet: how about rolling back all this BS and leaving things as they were?

      It's disaster just waiting to happen.

      O.

      1. doublelayer Silver badge

        "I've been using Linux for over well 10 years now and I can't recall the last time I had to look into a NTFS format drive."

        So because you don't need it, nobody else does either? If I unleashed that theory on the Linux kernel, I'd sheer off a ton of things I've never used. Compatibility with a number of processor types which I haven't used and don't plan to? Drivers for hardware that I don't have and isn't modern enough that I'm likely to get one. Lots of stuff in there I don't need, but that's a terrible argument for leaving it out.

        As for uses, I have repeatedly mounted NTFS disks on Linux recently. Sometimes, it's just reading (Windows laptop died, quick can I get the hard drive out and recover some documents). There are two situations which occur with regularity where writing is important. First, when repairing a Windows drive in some way, including disinfecting something that was strong enough to make it hard to delete in Windows. Guess what. In order to mount the disk read-write, Windows has to shut down cleanly and clear the journal, which Windows never does by default anymore. I have to boot the drive to Windows hoping the malware I'm trying to remove won't take any new steps on startup just to restart it. I would value a NTFS driver that didn't make me do that.

        Second, NTFS is sometimes used as the default filesystem for large external storage devices. The users plug it into their Windows machines and it shows up fine so they don't change it to something else. So to share a hard drive that I don't have permission to reformat, NTFS support is useful. If the NTFS driver has vulnerabilities, by all means hold it back until they're patched. But don't exclude it just because you don't use NTFS.

        1. windy_miller

          "In order to mount the disk read-write, Windows has to shut down cleanly and clear the journal, which Windows never does by default anymore"

          You have to disable "Fast restart" mode in windows.

          https://windowsreport.com/windows-10-fast-startup-dual-boot/

      2. katrinab Silver badge
        Paris Hilton

        If you have a TV that plays mkv files from a USB stick, as a lot of them can do, then you probably want it to be able to play them from NTFS formatted sticks.

        That's just one example.

  6. Ian Johnston Silver badge

    As a friend of mine used to say when he was doing algebraic topology in C and I was doing crystallography in C, "If you don't get compiler warnings you're not trying hard enough".

    1. Anonymous Coward
      Anonymous Coward

      And when you'd got rid of the warnings, there was some chance that your code was maybe correct to, if the results produced were good (coding god status conferred).

    2. Anonymous Coward
      Anonymous Coward

      If you don't get the compiler to spew 'Fatal Internal Error: Register 90 not initialised' you're not trying hard enough.

  7. Version 1.0 Silver badge
    Facepalm

    The word "git" has always been defined as "mildly derogatory, meaning a foolish or contemptible person" - that was seen as a joke originally when Git first appeared. A foolish or contemptible person is not an idiot and can be very good at some things (like writing software) even if you don't like them ... so the naming was a warning, not a joke - and it has turned out to be simply a fact of life.

  8. ST Silver badge
    Devil

    [ ... ] github creates absolutely useless garbage merges [ ... ]

    Linus is definitely not the only one to have reached that conclusion.

  9. RobHib
    Happy

    NTFS support added to Linux kernel 5.15 a good idea.

    I reckon merging Paragon's NTFS driver is an excellent idea. Leaving aside the obvious Linux/NTFS debate/dichotomy, interoperability between Linux and Windows has been and is still a problem, and making it easier will help the average user.

    Hopefully, Google will also incorporate this driver into Android, if so it would make OTG connections to external media much easier (as for now only some Android implementations have propitiatory NTFS drivers—Huawei for instance). Also, merging Paragon NTFS into Android would make interoperability with PCs, USB sticks something that users didn't have to worry about. Until now, I've found the lack of compatibility a real pain.

    1. Anonymous Coward
      Anonymous Coward

      Re: NTFS support added to Linux kernel 5.15 a good idea.

      I think all your use cases would be adequately covered by a GPL'd NTFS driver built on top of Fuse though. It's not like someone is ever going to want to boot Linux off of a NTFS drive is it? (Or are they??)

      After using it for well over a decade and *really* hating it when first introduced to it, I quite like Git now and even run the odd training session for newbies from time to time. I don't think I could stomach going back to svn even for a personal project.

      Everything anyone needs to know about git for day to day use is covered by the first two or three chapters of the Git book. https://git-scm.com/book It's a dead easy read too.

      1. MacroRodent Silver badge

        Re: NTFS support added to Linux kernel 5.15 a good idea.

        > covered by a GPL'd NTFS driver built on top of Fuse though.

        Which of course has existed for years ("NTFS-3G"), and most distros bundle it. I have not had any trouble accessing removable NTFS -formatted drives with Linux during the past 15 years or so.

        Hopefully the kernel driver works at least as well. In theory, it could have a better performance, but I'm not sure there are use-cases where it matters. For me as a Linux user, copying files on and off removable disks has been the only reason to mount NTFS volumes on Linux, and performance is not much of an issue for such use.

  10. Anonymous Coward
    Anonymous Coward

    Why are people complaining about keeping notes and not understanding the cli or commands?

    There have been good user interfaces on top for years and years.

    If you struggle with the cli or don't want to use it, just use one of the many other options that abstract the details away from you!

    1. M. Poolman

      You're missing the point, it's not the interface per se that is the issue but some of the underlying logic and (especially) the naming conventions for various concepts, as has been illustrated in many posts on this thread.

      Note that the story kicked off as a result of problems originating in a lovely cuddly web gui. There's more to computing than UIs !

  11. jmccabe

    I don't know why github's getting the blame here; I inherited a codebase that's full of useless and confusing merge commits, and those were all done from the git command line.

  12. Anonymous Coward
    Anonymous Coward

    So, my stance of 30 years ... vindicated ????

    I have never liked projects that seem comfortable with compiler warnings. They are there for a reason.

    If you don't understand the warning, you shouldn't be writing code.

    if you do understand the warning then you damn well know how to write it out.

    If a project that has always compiled with 0 warnings suddenly throws a warning you look damn hard.

    If a project that has "always thrown 100 warnings" throws one more then it's just more noise.

    1. M. Poolman

      Re: So, my stance of 30 years ... vindicated ????

      And you tell the young people today ...

    2. Anonymous Coward
      Anonymous Coward

      Re: So, my stance of 30 years ... vindicated ????

      The FreeBSD kernel has been compiled with warnings-are-errors for as long as the stars

    3. Anonymous Coward
      Anonymous Coward

      Re: So, my stance of 30 years ... vindicated ????..depends on compiler..

      I've used compilers where you turn on all warnings and watch carefully for all warning given. And I've used compilers were almost all warnings had to be turned off because 95% plus of the "warnings" were either because of some obscure ambiguous junk stuck into the language "standard" or the compiler was just simply wrong. Yes, I'm looking at you GCC.

      So turn off all warnings. Get code working. Turn on warning for a pass just to see if any of them are actually legit. Fix the very few that are. Turn off warnings again.

      Then you have compilers that merrily compiled incorrect code (no errors / warnings) so you had to run third party code through real compilers to catch serious bugs. Yes, I am looking at you again GCC.

      Then you have the "grammar police" compiler warning. About perfect legal and safe code that does not fits some guys opinion of what "good coding practice" is. The first to be turned off. Total bollocks.

      I love compilers where you turn on all warning by default. They save so much time. Not many of those about. In fact I have not used one on a shipping project in more than 15 years. And that cost $3K per seat. And worth every penny. But that was for an embedded project. So real engineers. But for everything else cheap and nasty.

  13. RLWatkins

    Using git is like driving a car without a dashboard.

    Sure, one can attach a vice-grip to the steering wheel stem to steer it. One can memorize the colors of the wires so one will know which ones to short out to start the car or turn on the windshield wipers. Without pedals one can operate the throttle by pulling a string. (More difficult to operate the brakes that way, but that's why dashless, pedalless cars have hand brakes.)

    Sure, one can do all these things.

    When we're all old we can tell our grandchildren, "When I was young, we didn't just have to walk to and from school uphill in the snow both ways while fighting off rabid bears, we also had to use git for source control, and we liked it." Bah!

  14. Cliffwilliams44 Bronze badge

    I always thought it was a colloquialism for the word Get.

    Like someone from East Tennessee saying "Git me my gun, Thelma!"

    1. MJB7

      Origin of "git"

      According to the author, it is because he is egotistical and likes to name software after himself; first "Linux", then "git".

      Also, his mother tongue is Swedish (he is part of the substantial Swedish-speaking minority in Finland), so he is unlikely to speak English with an East Tennessee accent.

      1. MacroRodent Silver badge

        Re: Origin of "git"

        Actually, The Man himself wrote (in "Just for Fun" p 88):

        And Ari Lemke, who insured that it made its way to the ftp site, hated the name Freax. He preferred the other working name I was using -- Linux -- and named my posting: pub/OS/Linux. I admit that I didn't put up much of a fight. But it was his doing. So I can honestly say I wasn't egotistical, or half-honestly say I wasn't egotistical. But I thought, okay, that's a good name, and I can always blame somebody else for it, which I'm doing now.

  15. Anonymous Coward
    Anonymous Coward

    Not sure it is applicable only to merge

    They should really workout GIT. I switched from ClearCase and working with GIT was everything but not joy and easy. Tool simply cannot be trusted; but it was 4-5 years ago.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021