Live data from Hacker News

Sapling: A new source control system with Git-compatible client

engineering.fb.com

511–520 of 543 posts

Re: Sapling: A new source control system with Git-compatible client

#511

Earlier quoted context omitted.

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.

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.

Re: Sapling: A new source control system with Git-compatible client

#512

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.

Not really, my .hgrc is about as long as my .gitrc, mostly 1 or 2-letter aliases in both. It makes both of them much easier to work with my workflow.

Re: Sapling: A new source control system with Git-compatible client

#513
post #493
post #466

Earlier quoted context omitted.

That's true, but that's not the whole story either. I remember not too long ago when it wasn't a big deal to jump from one VCS to another. Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard, would go from mailing patches to a ML on a project to pushing to a repo on another, to zipping code and uploading it on a FTP on a third. It was the project's workflow of choice, and people would respect that. Things re…

> Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard That's completely made up on your end. I've been doing FOSS for 17 years and the vast majority of people were barely competent with any of them at all beyond whatever their chosen ponyshow was (including off-brand ones like Darcs and Monotone), and any switching from a persons preferred one to the use of another project was often met with grunting and com…

Wow, what a pretty aggressive response.

> That's completely made up on your end. I've been doing FOSS for 17 years and the vast majority of people were barely competent with any of them at all beyond whatever their chosen ponyshow was

I doubt either of us has actual figures, so it's "my experience" vs "yours" (and full of anecdotal bias which I'm willing to admit). At least what's factual is that a decade ago, the versoning and tooling ecosystem was much more diverse: where today github/-actions/-CI/-issues/… is a quasi-monopoly you would bump into a new hosting solution/bug-tracking, reviews and CA build systems every other week, and the major open-source projects were either using CVS, SVN, GIT or HG. So, in proportions, more people had to be able to switch from a system to another, just out of practical considerations.

And I'm not even looking back pretending that things were perfect back then, I'm only suggesting that the monoculture which ensued killed a lot of competition, innovation and convenience, from which we could benefit today, on top of increased standardization (did you know for instance that hg can pull and push to git?)

> For every 1 person doing this 50 just stuck with whatever they used and wouldn't bother. I've literally seen people refuse to contribute to a project over tabs vs spaces, and people still do this with git vs hg today, just not as much today.

There's some truth to that, but it's a pretty extreme view. All projects can benefit from a lower entry bar and should be as welcoming as feasible, but optimizing for drive-by contributions at the expense of more meaningful involvement is destructive on the long run: anyone having worked on larger projects knows that the bulk of the effort is carried by a smaller group of dedicated people over long periods of time, not hundreds of over-the-fence-throwing typo-fixes. And I'm totally siding with projects who don't want to adopt the github ways of organizing their work where it means making long-haul contributor's lives more difficult.

> More people use Git and contribute to FOSS in a single day in 2022 than every developer who knew all these tools combined back in 2008 or whatever.

[Ref. Needed]

> > Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.

> Sorry, but I consider this to be a similarly made up claim that's just sour grapes.

If "gamified" may not be the right term, you certainly can't be oblivious to how often people equate their github activity to their resume, and how it's used as a token of value by job hunters and recruiters alike. Putting aside the "merit" of most contributions, this really contributed to people "demanding" from projects to move to github, to bring visibility on themselves (before the interests of the project itself), hence the centralization around the single largest platform. I don't know about you, but I find this state of affairs quite discomforting.

Re: Sapling: A new source control system with Git-compatible client

#514
post #120
post #87

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

Using lazygit has improved my usage of Git so much! There is a nice video from the author that introduces a lot of its features.

[0]: https://www.youtube.com/watch?v=CPLdltN7wgE

Re: Sapling: A new source control system with Git-compatible client

#515

> When used with our Sapling-compatible server and virtual file system (we hope to open-source these in the future) Sorry, I just can't take an "open-source" project seriously that uses "we hope to open-source these in the future" in its pitch.

The source is already available in the eden/mononoke and eden/fs directories and are licensed under the GPLv2.

Hm? GPLv2 sounds like open-source to me - unless the OSI hasn't approved GPLv2 (they did[0] approve GPLv3). Is the article simply out of date?

[0]: https://opensource.org/node/193

Re: Sapling: A new source control system with Git-compatible client

#516

Earlier quoted context omitted.

“PHP-like but incompatible” isn’t in itself a useful feature — it is the thing which unlocks a bunch of useful features (a sensible standard library, sensible list/dict datatypes, typed collections, XHP, async functions, generics)

I get that. A superset could be interesting. Downright incompatible seems to tip the balance the wrong way.

PHP is a fractal of bad design[0] and creating a superset will not enable you to create a better language.

[0]: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Re: Sapling: A new source control system with Git-compatible client

#517
post #269

I'm kinda surprised by the excitement it gets. I'm still looking for a compelling explanation, why I (or anyone else) should even bother? I am a git hater myself. I mean, git just sucks. It always did, and it always was much worse than Mercurial. When they could have be seen as competition, I was forcing Mercurial as much, as I could, but then GitHub became a thing, and after a very short struggle it became just hope…

Its like Fish shell vs Bash shell. Bash has weird defaults so you end up googling for everything. In fish, it just works and you barely need to search for anything. Sane defaults matter. With hg, I don't need to struggle to get it to do what I want, it just gets out of the way. With git, sure it works but like you said it has a bunch of ducktaped tools together that change the defaults or just generally make things e…

> In fish, it just works and you barely need to search for anything.

I keep having to google the location of my configuration file. It's ~/.config/fish/config.fish. I think, if it's not in ~/.local.

The whole function thing is also not the easiest to understand, although I love that it hot reloads and is global across all instances and so on, along with all sorts of other things.

Overall fish is one of my favorite shells but it's not 100% intuitive at first.

Re: Sapling: A new source control system with Git-compatible client

#518
post #439

Earlier quoted context omitted.

Not my experience. As it happens, Mercurial and Git are very similar in terms of the "mental model" required to use them: history is just a DAG, and common operations consist of navigating the history and creating/editing/re-organizing commits. But where mercurial shines with a clean, consistent and simple UX, git is a mess where storage-layer abstractions leak to the user and where single commands serve multiple unr…

I really love git for the way it has taught me so many things by being so exposed. I love that you can easily use it as p2p, via email as a server or client, as a ci/cd solution. I love that you can easily inspect its model with cat. I love that while “branches” and “tags” seem special, you could just as easily use its “notes” or even just tack on your own ref system willy-nilly. All this to say, I love git, and as a…

It’s like the affection I feel for C++ after I’ve re-learned one of its umpteen quirks for the umpteenth time.

Re: Sapling: A new source control system with Git-compatible client

#519
post #431

Earlier quoted context omitted.

git reset --hard origin/master just deletes all your local work on the current branch.

I never want that though. If I wanted to do something like that, I'd do the git reset soft, followed by git stash, followed by git switch. I think this at least allows me to look back at it locally? Git switch is also something I learned recently so sometimes I type checkout because of force of habit but I am trying to do better (even though I'm not sure what switch dies that checkout can't but don't want to get into…

The thing about git is that it's basically plumbing all the way down. In this case: switch abstracts over checkout, which abstracts over read-tree & checkout-index. The nesting doll just keeps going.

Because switch is built on top of checkout, there's no functional difference between the output of the two subcommands when used for the same purpose (assuming the presence of a skilled operator). It's strictly a matter of ergonomics and abstraction.

At the end of the day, as long as you don't fuck up, just do whatever best keeps you in your flow state.

Re: Sapling: A new source control system with Git-compatible client

#520

Earlier quoted context omitted.

React Native, named after their open source project that is incredibly successful, widely used, completely reshaped the front end dev world, etc... Not sure if an offshoot of a world class project not gaining traction is a mark against them.

It didn’t reshaped the mobile dev world though.

In a way it has. Just not directly. Everyone is abandoning (for example on iOS) imperative style (Cocoa and UIKit) for React style (RxSwift, ComponentKit, SwiftUI). It's the biggest shift in native UI programming in more than a decade.
Post reply on HN