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. …
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
So:
* 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.
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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
