Git is and always was very fast. Hg used to be much much slower, and still is.
Mercurial beats git in a fair bechmark on a large repository by now. As far as I know, no other DVCS received similar dedicated optimizations. (Microsoft worked around git by shimming a fake file system driver below the local repository to make it scale enouth to cover the Windows codebase. It's all Windows exclusive and not part of git, so it doesn't really count).
They asked to add it to Git, however they are rejected.
I've never heard of mercurial until this post, I've been using git for version control and it does the job really well. To those who use mercurial over git, why?
Seems to be popular at Facebook.[1] Where I work Mercurial has been an option for some time now (no Git unfortunately) and coming from Git I must say I really love how it does some of its things: - hg split: split a commit into as many different commits as you like using an interactive patch editor (you can fold/collapse hunks, can edit them textually, can select which lines of the hunk should be applied). It will au…
I've been using lazygit [0] for a lot of use cases like this and it's been great. It's a terminal UI with a bunch of shortcuts. In particular, the partial commit is awesome, as is the ease of amending.
A couple others mentioned Magit which I think is similar.
FWIW I learned Mercurial before I learned Git, and SVN before that. Mercurial was great. I still think its commands made more sense than the Git ones, especially coming from SVN.
"So in moving it to GitHub, we’re finding that a lot of things are just nicer because a large paid staff of engineers is working on it every day. And I grew up during the heydey of the Free Software Foundation, so I know this is a trap, but I’m tired and don’t have the energy to be a server admin for something that’s held together with scotch tape and prayers when I’m really supposed to be writing OpenGL code." This…
Personally I find this far more worrisome signal of the health of foss ecosystem than the quibbles between elastic and amazon. To me the idea of software "by hackers for hackers" and scratching your own itch has always been one of the key attractions in FOSS ecosystem, but somehow now our itches seem to have outgrown our ability to scratch then. Doing almost anything yourself feels impractical these days. This is als…
FOSS has always been plagued by the 80/20 rule. Most of it is garbage, of the remaining quality software most are no longer maintained, of the remaining maintained most are slowing in development, and of the very few left that are healthy and active, most are shepherded by a private company or two.
Personally I find this far more worrisome signal of the health of foss ecosystem than the quibbles between elastic and amazon. To me the idea of software "by hackers for hackers" and scratching your own itch has always been one of the key attractions in FOSS ecosystem, but somehow now our itches seem to have outgrown our ability to scratch then. Doing almost anything yourself feels impractical these days. This is als…
FOSS has always been plagued by the 80/20 rule. Most of it is garbage, of the remaining quality software most are no longer maintained, of the remaining maintained most are slowing in development, and of the very few left that are healthy and active, most are shepherded by a private company or two.
The only software that actually dies is closed source. And with it, all the money you spent on it.
Personally I find this far more worrisome signal of the health of foss ecosystem than the quibbles between elastic and amazon. To me the idea of software "by hackers for hackers" and scratching your own itch has always been one of the key attractions in FOSS ecosystem, but somehow now our itches seem to have outgrown our ability to scratch then. Doing almost anything yourself feels impractical these days. This is als…
> Doing almost anything yourself feels impractical these days. I would argue this is only the case because we've created an intentional social and skill gap in the industry between server administration and operations work and software development. My experiences, especially more recently, have been shocking in how little the average software developer knows about /very basic/ server administration. I don't have a fu…
Most folks don't _need_ much more than a LAMP-equivalent running on a virtual host somewhere.
Why bother installing k3s and whatever deployment-tool-du_jour it is these days, when dropping some files on a host is good enough?
For better or for worse, this is nothing new. It is a symptom of the fact that the FSF and other FOSS organizations have displayed a fantastic failure of technical leadership for over 3 decades. The political leadership has not been bad, but if you go back and dig through the history of open source you will see that there have been multiple repeated failures by the supposed thought leaders to provide the equivalent l…
> It is a symptom of the fact that the FSF and other FOSS organizations have displayed a fantastic failure of technical leadership for over 3 decades. I agree that many FSF/GNU projects have made horrible technical choices, but I don’t think that’s really the root cause here. The reality is that good software requires an enormous amount of skilled labor to create and maintain, and the FSF and other OSS orgs can only…
And of course, no closed software has _ever_ had a poor UI/UX.
FOSS has always been plagued by the 80/20 rule. Most of it is garbage, of the remaining quality software most are no longer maintained, of the remaining maintained most are slowing in development, and of the very few left that are healthy and active, most are shepherded by a private company or two.
The only software that actually dies is closed source. And with it, all the money you spent on it. FOSS will outlive us all.
There's plenty of dead FOSS. Anything that relies on a library or build toolchain that's hard to find or configure comes to mind.
Go spend some time trying to get RHIDE working, for instance. You're going to have to bring it back to life to do so.
And yet, closed source seems to run just fine in emulation.
I think GitHub is generally safe as long as you have an exit plan for when it's no longer the place you want to be. Know where you're moving your issues and actions if you decide you need to leave.
If you're not actually using your backup plan it will likely rot. And if you have a usable alternative, why wouldn't you just use it?
That community aspect. You get more drive by participation from GitHub, which is valuable in itself.
The only software that actually dies is closed source. And with it, all the money you spent on it. FOSS will outlive us all.
There's plenty of dead FOSS. Anything that relies on a library or build toolchain that's hard to find or configure comes to mind. Go spend some time trying to get RHIDE working, for instance. You're going to have to bring it back to life to do so. And yet, closed source seems to run just fine in emulation.
Luckily, I can bring it back to life.
Good luck emulating! That emulator's probably based on FOSS. :)