521–530 of 543 posts
As a Meta employee for almost 4 years what I will say is I was skeptical at first coming from git, but the sapling system works very well in practice in my experience. I still use git for everything outside of work, but I may consider sapling now.
Earlier quoted context omitted.
React Native hasn't yet reached v1.0. Or several critical issues hasn't been addressed yet as of now.
There recently was a thread here on the impact of layoffs on React. And apparently even Facebook has abandoned react for anything but internal projects.
I... what? Do you have a source or speculating to create fear of future support?
I'm nearly certain this is untrue.
Earlier quoted context omitted.
My experience is the opposite. Most of the staunch Mercurial supporters came from CVS or SVN and found Mercurial to fit better into their preexisting mental model of source control. Users that started with Git are more likely to internalize Git's concepts as "the natural way to do version control", and more likely to find Mercurial counterintuitive.
People don't internalize Git concepts as "natural", they get Stockholm Syndrome. I'm not saying mercurial is better, but there's a reason I have to remind people that this[1] is satire - the real manuals are so convoluted that they seem like parodies of themselves. [1] https://git-man-page-generator.lokaltog.net/#c2NyZWVuJCRnYXJ...
Earlier quoted context omitted.
What are the changes that Mercurial has? I've read many times that Mercurial is easier but I've never seen the reasons. The times I've used mercurial (mostly to download a repo) it doesn't look that different, and other than the staging area weirdness I don't find git too difficult.
You know how when using git you have to add tons of flags to every command to make it do what a sane person would actually want? Mercurial just does what you want.
I have used (actually introduced) Mercurial before at a company and considered them basically equivalent enough, only to get stuck in some horrible design choices of early Mercurial (named branches and not having rebase by default). I am happy to see these elements corrected in Sapling, giving me enough confidence that I might actually use Sapling over time...
Earlier quoted context omitted.
There recently was a thread here on the impact of layoffs on React. And apparently even Facebook has abandoned react for anything but internal projects.
> And apparently even Facebook has abandoned react for anything but internal projects I... what? Do you have a source or speculating to create fear of future support? I'm nearly certain this is untrue.
Earlier quoted context omitted.
There recently was a thread here on the impact of layoffs on React. And apparently even Facebook has abandoned react for anything but internal projects.
> And apparently even Facebook has abandoned react for anything but internal projects I... what? Do you have a source or speculating to create fear of future support? I'm nearly certain this is untrue.
Thank god. I have been waiting ten years ( https://www.google.com/url?q=https://stevebennett.me/2012/02... ) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it. This looks incredible. A simple command to uncommit or unamend makes you further realise what a dis…
Ah, there it is. I was wondering when this would happen. Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions fro…
I switched from git to Mercurial and was absolutely gobsmacked by how much better it is. The only comparison was switching from a Blackberry to an iPhone - everything just works exactly the way I want it to. Yes, I read the manual for git, but I never needed to for Mercurial.
Thank god. I have been waiting ten years ( https://www.google.com/url?q=https://stevebennett.me/2012/02... ) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it. This looks incredible. A simple command to uncommit or unamend makes you further realise what a dis…
I've been using lazygit[0] for a while, which might not be what you're looking for but I enjoy it a lot. [0]: https://github.com/jesseduffield/lazygit
Earlier quoted context omitted.
I don't blame git, I'm mostly surprised about the social inertia regarding improving it. But like programming languages, pressure accumulate until it's released, I'm sure sapling and similar will make people want to try new things and git will soon catch up.
The social inertia point is an interesting one. It seems like in some areas, like JavaScript frameworks, there is a ton of inertia for change; in other areas, like git, there is a ton of inertia for stasis. Why is that?
But with Git, every conversation about improving the CLI has 50% of the participants claiming that the other 50% are just too stupid to use it, and that the CLI is brilliant.