Have heard of some FAANG (meta, google..) moving to Mercurial. Any merit in that?
Ask HN: Can we do better than Git for version control?
91–100 of 309 posts
Re: Ask HN: Can we do better than Git for version control?
#92It would be hard to get past the network effects. Just like how we are stuck with SMTP, JavaScript, PDF, HTML, etc. The only way I could see it changing is if we have a complete paradigm shift. This is what happened when we went from SVN to Git (centralised to distributed).
SVN is only 5 years older than git, and while git is distributed, people basically use it like it's a centralized VCS these days.
Re: Ask HN: Can we do better than Git for version control?
#93Subversion was really good. It wasn't perfect, but it was relatively painless. Instead everyone switched to a "distributed" version control system that is such a pain in the ass it is all now hosted by a single company.
Many companies host git besides github (gitlab and bitbucket to name two), and you can spin up one of your own in about 1 minute on your hardware or on a private cloud vps. A github server is much easier to set up than a subversion server. The reason people use github is because it's free, and because it has issue tracking and a wiki and forking which plain git knows nothing about.
> A github server is much easier to set up than a subversion server.
You can't set up a GitHub server.
Re: Ask HN: Can we do better than Git for version control?
#94Re: Ask HN: Can we do better than Git for version control?
#95Many tried, few succeded. SVN - client-server principle, but bad at merging branches mercurial - one of the competitors after the linix kernel devs searched a new version control system, its users die out, since git is more popular, very similar to git bazaar - mostly used for ubuntu, since launchpad is only providing bazaar as vcs
Launchpad added Git support years ago. Also, bzr pre-dates git by a tiny bit, too. But sadly git won.
Re: Ask HN: Can we do better than Git for version control?
#96A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare…
Git keeps the entire history on your local machine, this becomes a problem if your project grows to several hundred GB (not untypical in game dev). Even SVN was much better for working with large repositories, you only needed a big server. Git is quite nice for "source code only projects though".
Re: Ask HN: Can we do better than Git for version control?
#97Of course there is a room for improvement... One of the biggest issues is usability/user experience: pull, fetch, checkout, commit, push, rebase - what is all this and what is the exact meaning? I need simple English terms for my work - like update and save - nothing more. Why do I need to worry about implementation details and terms? If I can not explain it to my wife, then I can not use it for binary documents whic…
Imagine an electronic engineer complaining about an oscilloscope being hard to use because he cannot explain what all those knobs do to his wife. We are professionals, our tools should be powerful for the advanced user, not beginner friendly.
Yes, but if the oscilloscope has some buttons that take out the entire company’s codebase if pressed wrong.
Re: Ask HN: Can we do better than Git for version control?
#98Yes.
IMHO the next VCS model should follow a centralized-first, decentralized optional model. Which would be a flip of the decentralized-first model of git.
I also think GitHub is in a unique space to really innovate on git and it’s a shame they’re not.
For example, I shouldn’t need to make a fork to make a PR. That’s absurd and the GitHub server should be able to apply ACLs based on the push identity.
There’s a couple more of these suggestions I can think of, but yeah, GitHub should do more in this space.
Re: Ask HN: Can we do better than Git for version control?
#99Have heard of some FAANG (meta, google..) moving to Mercurial. Any merit in that?
yep both extended it and have versions that can work against GitHub/git servers.
sapling scm from meta has I think the best cli and VS code UX https://sapling-scm.com/
jj from google is also mercurial derived with very similar cli features like histedit and has support for deferring conflict resolution https://github.com/martinvonz/jj
Re: Ask HN: Can we do better than Git for version control?
#100Of course there is a room for improvement... One of the biggest issues is usability/user experience: pull, fetch, checkout, commit, push, rebase - what is all this and what is the exact meaning? I need simple English terms for my work - like update and save - nothing more. Why do I need to worry about implementation details and terms? If I can not explain it to my wife, then I can not use it for binary documents whic…
Imagine an electronic engineer complaining about an oscilloscope being hard to use because he cannot explain what all those knobs do to his wife. We are professionals, our tools should be powerful for the advanced user, not beginner friendly.
A tool can be both beginner friendly AND powerful for advanced users.
Speaking of your analogy, the role that most software developers fullfil is not an engineer wondering about the oscilloscope, but rather the construction worker installing electrical fixtures wondering why the cable clamp has such a weird interface. Both the oscilloscope engineer in an office and the worker doing the field work would benefit from having a simple and reliable tool fit for purpose of cable clamping.
There is certainly a need for competent and "proper" software engineering that require special tools and detailed training, but I would argue it's niche and filled by people who build the tools themselves.
IMO the largest share of developers today are doing brick-laying work (which of course takes skill, I am not underestimating it) and would benefit a lot from having simpler tools - they don't need to know how to use an oscilloscope at all.