back to article Popular open-source library SDL moving development to GitHub despite 'calamitous design choices' in git

The Simple DirectMedia Library (SDL) project is moving development to GitHub today despite what a core developer calls "calamitous design choices" in git, for the sake of familiarity and wide tool support. SDL is a cross-platform and open-source multimedia library mainly written in C and widely used in game development. …

  1. Tom 38 Silver badge

    github issues can be converted and stored in git using git-bug using two-way bridges, which is pretty sweet (Jira and Gitlab issues too :)

  2. ThomH

    In the industry that embraced x86 clearly calamitous design choices are no obstacle to market dominance, and being dominant usually means being the best tool for the job. SDL's move is the right thing to do. If anything, the hand-wringing feels a bit overplayed.

    1. yetanotheraoc Silver badge

      hand wringing

      It probably followed a logical path from shorter internal email, to longer blog post, to current El Reg interview piece, and playing soon as another internal email.

    2. sabroni Silver badge

      re: being dominant usually means being the best tool for the job

      Upvoted for saying that MS should have been allowed to leave IE as default in Windows?

      1. needmorehare

        IE had some things going for it at the time

        IE had integrated Adblock (TPLs) and a means to auto-generate rules, a decent P3P implementation, support for standardised content ratings systems and implemented security sandboxing before Mozilla Firefox ever did. Also, ActiveX was superior to NPAPI and ironically more secure despite what fanboys claimed at the time (PPAPI was ultimately better but that came much later with Chrome).

        If Microsoft hadn’t left the core of their Trident engine to rot so badly, it would have stood a good chance of winning the browser wars. Instead, we now have Microsoft Edge and Google Chrome resting on their laurels.. maybe it’s time for someone at Microsoft to Make IE Great Again?

    3. Charlie Clark Silver badge

      The handwringing isn't overplayed at all. But the risk isn't necessarily everything going into git repositories but that of the risks inherent in any monoculture.

  3. karlkarl Silver badge

    Mirror to GitHub, GitLab, BitBucket and run your own bug tracker. This seems to work well for us. It also means we can get more control over the public and private bug tracking.

    1. Will Godfrey Silver badge

      The project I work on started on sourceforge, then mirrored to github when sourceforge had that major wobbly. I still like various aspects of sourceforge, and find it much nicer for historical searches and bug report management.

      1. foxyshadis

        On the other hand, I won't work with a project that uses SourceForge anymore, because it's simply too clumsy, too backward, and too impossible to use compared to its peers now. Even back in the day, it was only acceptable because no other platform was doing what it was doing.

  4. nijam Silver badge

    I'd like to know, purely out of personal interest, what the "calamitous design decisions" were.

    Unless it was simply a way of saying "it's not what we're used to" without actually saying it.

    1. Phil Lord

      The UI sucks. Compare

      git worktree remove fred

      git branch -d fred


      git branch add

      which adds a branch called "add". It's all just so weird.

      1. ThomH

        You mean git push origin :branchname doesn't immediately say "remove the branch branchname from wherever it is you have set as the origin repository" to you?!?

        1. teknopaul Silver badge

          I have been using git for many years and have learned two things.

          1) never read the man page.

          2) rm -rf & git clone

          every terminology choice except its title is confusing.

          I have a wrapper called Mr Nice guy, that makes the ol git bearable but I hate it.

          There is nothing intrinsically wrong with single source of truth for 99.999% of projects.

          1. sreynolds Silver badge

            So in (2) you rm -rf in the background nothing and then start cloning?

            I don't think that torvalds has ever rm -rfed his .git dir? He just asks that git fixes it. In fact, I think that he clones temporary repositories from that same .git dir, that is probably called tridgekilledbitkeeper.

      2. DrXym Silver badge

        Deleting a branch in Git used to be little weird (pushing a delete command with a colon) but the syntax was fixed and is relatively sane these days. And creating a branch called "add" did exactly what you asked it to do. Do you think it should reserve names that you can't call a branch and why would that be any better?

        Personally I think the bigger learning curve with Git is one it shares with Mercurial - the concept of clones, pushing and pulling. Anyone used to Subversion or CVS takes a while to get into that concept. Beyond that, both Mercurial and Git work in a similar fashion and it's a matter of just getting used to it. There are some very good graphical frontends too, and most IDEs these days have very good integration with it.

    2. Alan Mackenzie

      Calamitous design decisions in git

      In git, basically the internal structures are fantastic and the UI is utterly undesigned.

      Mercurial has the same power as git, roughly speaking, but has a single well written comprehensive man page whose .bz2 file is a little over 100 kB.

      git has a man page for every command (around ?150, I think), and their total bulk, again as .bz2s, is over 800 kB. Some of these git man pages are 2000 lines long, containing descriptions of reams and reams of parameters the commands take. The corresponding sections in the hg manual are perhaps 40 to 60 lines long. The ghastly state of the git documentation is the stuff of legend.

      As somebody who uses both, I say Mercurial is by far the better piece of software.

      1. sreynolds Silver badge

        Re: Calamitous design decisions in git

        Beta was vastly superior to VHS, or so says my grandpa.

      2. cyberdemon Silver badge

        Re: Calamitous design decisions in git

        And then there's Git's submodules (which can definitely be called calamitous) , subtrees (which are a better implementation but an even worse user interface) vs mercurial's subrepositories, which I've never used, but I'm assuming are much better designed than Git's two competing attempts at the same thing.

    3. Anonymous Coward
      Anonymous Coward


    4. Michael Wojcik Silver badge

      The real calamity is using a central server like GitHub, which is not what git was designed for.

      git makes a lot of sense for Linux kernel development and other truly distributed projects. For projects that insist on a central store, it's daft. I don't know how many times I've done a git pull only to be greeted by incomprehensible errors which can only be fixed by running garbage collection (and what is the point of GC that has to be triggered manually) and/or other mysterious "local cleanup" operations. And there are other issues; for example, storage of binaries (which shouldn't be in the repository, but people insist on adding them) is inefficient.

      People insist on forcing git into workflows where it works poorly, and GitHub and IDEs are major offenders in that regard.

  5. Anonymous Coward

    Is big better?

    The telling quote in the article is that GitHub has "a large paid staff of engineers is working on it every day."

    That was the selling point here and I suspect it is for many developers. Without depository developers, depositories fade away.

    But with developers, GitHub (and M$) start to dominate.

    Unless the developer community can develop a plan to counteract this, we will be left with accepting it and griping about the good old days.

    1. Tomato42
      Thumb Up

      Re: Is big better?

      I don't see how MS "dominating" code hosting is a problem, especially when every developer has a full history of the code on their machine.

      They are providing service for free (have you tried Github Actions for CI, it's bloody fast, completely unlike Travis, even before they kneecapped it). If they do that just to have better integration with Visual Studio, then I don't care one bit; don't use it, don't need it.

      Now, as a maintainer, my biggest issue is the backlog of issues that demand attention, so I'll use the hosting that is most popular, most well known so that I have chance to get people to help me and to minimise the barrier of entry to new people. Spending time maintaining a mailing list server, hg server and MoinMoin wiki doesn't help with any of that.

      So yeah, good on ya SDL.

      1. Robert Carnegie Silver badge

        Re: Is big better?

        Next month, Microsoft claims a share of copyright in all of your program code. It could happen...

        Then your software, stored in Microsoft's environment... is in Microsoft's environment...

        1. Tomato42

          Re: Is big better?

          riiight, because where the code is publicly hosted is an iron-clad defence against this

        2. DNH

          Re: Is big better?

          If I owned GitHub, I wouldn't be looking for opportunities to grab IP from the 'users'. I'd be running AI analysers all over the content. This analysis might first be manifested as much better tips and help from your IDE to avoid errors. Later, automatic code generation could improve so that a lot of actual programming tasks become redundant.

      2. teknopaul Silver badge

        Re: Is big better?

        You don't have a full copy of history and you never will if anyone pushed a rebase.

  6. gerdesj Silver badge
    Paris Hilton

    git is self aware?

    "and that git has made some calamitous design choices"

    git was invented by Mr T for one purpose - Linux kernel source shenanigans. What others do with it is their business. git itself couldn't give a shit. Perhaps the bloke meant to say "github".

    1. teknopaul Silver badge

      Re: git is self aware?

      IMHO it's only good for kernel dev. almost everything else wants a coherant single source of truth, a backup, and non editable history.

      git fails on all three unless you use a perforce backend.

      1. Anonymous Coward
        Anonymous Coward

        Re: git is self aware?

        Perforce is the worst pile of garbage since Microsoft Source Safe.

      2. Anonymous Coward
        Anonymous Coward

        Re: git is self aware?

        Wash your mouth out! Perforce is an abomination. I am fairly sure Github nudges you away from trying to publish a rebase. i.e. you have to click through several warnings on the Web UI or delete the old branch first to get it to accept it.

        Who rebases their branches anyway? That's a step along the path to insanity.

    2. Steve K

      Re: git is self aware?

      git was invented by Mr T for one purpose

      "I ain't using no code repository, fool"

  7. Jonathon Green

    Meh. Git is just another in a long line of CMS/RCS tools which aren’t as good as ClearCase. Which is easy for me to say as I’m not the one who has to pay for the infrastructure and support staff needed to keep a good sized ClearCase installation running smoothly...

    1. DrXym Silver badge

      I used to work for a company that needed to hire 2 full time admins per *site* to run Clearcase because it was so garbage slow over a WAN they needed to replicate everything to run it locally. I reckon they were spending £200,000 just for that not to mention devs who sat around twiddling their thumbs waiting for syncs to happen. And the licensing costs for the software must have been eyewatering because they were always begging people to close clients down to free up some floating licenses.

      I wouldn't wish that crap on my worst enemy.

      1. Anonymous Coward
        Anonymous Coward

        When I worked at one of the big five tech companies, just a few years ago, the complete setup was this:

        There is a monolithic repository, which originally you could check out. But at some point it got too large for that to be realistic. So they added cloud-based clients, with some local caching, and that became the only supported way to interact with the repository, becoming assumed in the process for generating pull requests, getting colleague review, etc.

        But then the size of the repository grew further and relying on cloud-based clients became problematic in many of the satellite offices. So they added a front-end that sets up a local repository containing only subsections of the real repository, which it fetches from your cloud client.


        * one big repository, clone locally;

        * that's too slow, put another layer on top and keep it in the cloud;

        * that's too slow, put another layer on top and keep it locally.

        1. Michael Wojcik Silver badge

          Well, yeah. Any problem can be solved by adding another layer of abstraction.

          When I was at IBM many years ago, I was part of a small team. We were using RCS for revision control - this was before the original CVS release, even - and kept the master source repository on a network filesystem (AFS). RCS keeps its data alongside the working files (directly or in .rcs subdirectories), but we couldn't do development in the master tree, not just because it would be foolhardy but because our builds would conflict. So I wrote scripts that would create local shadow trees with symlinks to the RCS and working files, and wrappers for the various RCS commands that knew how to deal properly with the shadow tree (e.g. deleting the working-file symlink before checking out a copy for editing).

          A few years later, at another company, I created a fully client/server networked version of RCS for OS/2 and OS/400, so we could use RCS for our OS/400 development without having to port all the other gubbins such as diff3. (This kept the RCS exclusive-checkout paradigm, so it wasn't as ambitious as CVS.)

          Just additional layers of indirection.

          These days, most of the projects I work on use Subversion, which is very well suited for them. A few use git with GitHub Enterprise, and it's a poor fit, because pretty much everyone uses it as a Subversion-style CMS but with a terrible user experience. Sometimes people make pull requests, but they're just formalities; it would work just as well to send a message to someone asking if it would be OK to merge a feature branch.

    2. Anonymous Coward
      Anonymous Coward

      The 1990s called: they want their Rational modelling tools back.

  8. teknopaul Silver badge

    terminology crazy.

    rm -rf means exactly what you think it means.

    I use it in scripts, but I still don't know what git rm -rf means.

    svn for all its ills has a version number for every version that means something now and for ever.

    Same cannot be said of any git commit.

    a "git commit" means many things but not what every human being has ever meant by the word "commit" before git was invented.

    Every design choice in git was backed by a word that might as well be Finnish.

    clone doesn't clone

    push doesnt push

    pull doesn't pull

    branch doesn't branch

    rm does not remove

    status tells you nothing that you don't have locally already.

    commit does not commit

    rebase does not mean anything anyway

    reflog means mean ref nor log

    pull has nothing to do with pull request, n. b. pull request is not even a part of git.

    origin is not the origin

    master is not the master.

    "detached head" is close, at least its how you feel when it happens.

    the only correct term is git.

    1. boblongii

      I guess you copied these off a trolling blog post somewhere. If you'd used git you would know that most of them are simply not true and others are meaningless - master is not the master; origin is not the origin etc.

  9. Potemkine! Silver badge

    The project switched from Subversion to Mercurial in April 2010, and before Subversion was on CVS (Concurrent Versions System), so in a sense it has followed a typical path as popular systems have declined when something better came along.


    1. Michael Wojcik Silver badge

      What, you don't remember the mass migration to Mercurial that started around April of never?

      Mercurial may be swell, but to the best of my knowledge it's never been more than a niche player.

  10. Anonymous Coward

    "when something better came along"

    Something more fashionable, you mean...

  11. Brewster's Angle Grinder Silver badge

    Every time I start a new project I think, "I must get better acquainted with git and really seriously use it." Then I type hg init and get on with work.

  12. Anonymous Coward
    Anonymous Coward

    Git is like Linux. It takes time to learn, and most people are too lazy.

    Fortunately, a new generation of developers are coming through who wouldn't consider anything else.

    1. Anonymous Coward
      Anonymous Coward

      > Git is like Linux. It takes time to learn, and most people are too lazy.

      As we used to say about UNIX: it's extremely user friendly, just a bit choosy as to who its friends are.

    2. Michael Wojcik Silver badge

      Bah. The new generation, like the previous generation, is always worse than the current generation.

      On a more serious note, I try to avoid the error of believing my personal preferences are evidence of superiority. (I mean superiority in the things I prefer; obviously they're evidence of my personal superiority.) My preferred editor is vim, and I get cranky1 if I'm asked to use anything else. But I'd never suggest anyone else should adopt vim. I mean, if you like it, great; but it is a relic of another time and does not objectively make sense for most users.

      I've used git for years, and I continue to hate it. But I think it is appropriate for its intended application. And that it's wildly misused for other things, so I don't see any reason to cheer its spread. You may feel differently, but that is not, in itself, evidence that git's dominance is a good thing.

      1I was going to write "I get unpleasant", but then it occurred to me that I'm always unpleasant.

  13. Charlie Clark Silver badge

    Other options are available

    I'm moved my Mercurlal projects to Heptapod when Bitbucket decided to fuck us over. They managed the import and, contrary to many expectations, the projects continue to receive contributions.

  14. Claptrap314 Silver badge

    Github action?

    Nope. Just nope. It was hard to tell if they were more blatantly a security failure or a vendor lockin when they were introduced.

    Nope, nope, nope.

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

Other stories you might like