Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

engineering.fb.com

Post reply on HN
Print view View original

431–440 of 543 posts

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

#431

Post by pooper »

bombolo wrote: post #349
pooper wrote: post #147

Earlier quoted context omitted.

I don't know much about git but I just do git reset --soft HEAD~n where n is the number of commits I want to undo. Known issue: can't undo all the commits.

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 arguments, just want to do things the prescribed way).

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

#432

Post by hoosieree »

nemetroid wrote: post #410
riquito wrote: post #268

Earlier quoted context omitted.

I guess you didn't start from cvs or svn, because the experience moving to git was otherworldly. If git was your first versioning system than you had to learn some concepts first, which you already internalized when you switched to Mercurial.

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...

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

#433

Post by durham_meta »

jsmeaton wrote: post #379
durham_meta wrote: post #82

Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.

Does sapling support hooks like pre and post commit? My workflow leans on pre-commit (the framework) heavily and it would be hard to give that up. I’d still be keen to take this for a drive though, nice work!

Technically the mercurial pre and post hooks are mostly still there, but I'm not certain we want to support them long term. The existing hook design has some problems.

I'd be curious about your use case, since we don't actually use hooks internally all that much.

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

#434

Post by martinvonz »

pmeunier wrote: post #390
softjobs wrote: post #29

Earlier quoted context omitted.

And https://github.com/martinvonz/jj .

Because it is based on Git, jj is not a CRDT, it seems to be a better merge algorithm (even though the details on their algorithms are scarce). When I say "not a CRDT" I'm obviously talking about HEAD not being a CRDT, a Git repo is append-only, so the history of a Git repo actually is a CRDT (but that's not what the comment above meant).

I think the more important thing is that jj (and hg and git) don't use the AST at all, at least not yet. Does Pijul?

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

#435

Post by trilobyte »

durham_meta wrote: post #82

Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.

Thank you for answering questions. I was poking around Sapling and got thrown off track pretty quickly. Just wanted to init an empty repo but on an Intel MBP I just get an error:

`abort: please use 'sl init --git .' for a better experience`

What's going on here? I couldn't find info in the `sl init --help --verbose` output or in the Sapling website.

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

#436

Post by selfhoster11 »

stevage wrote: 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 got 90% of the way there with a lot of git aliases. The other 10% is constraining your workflow and reasoning about what state each of your commands leaves the git tree in.

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

#437

Post by durham_meta »

wocram wrote: post #358
durham_meta wrote: post #104

Earlier quoted context omitted.

The code is available to see, but they don't necessarily build in an external environment yet and even if they did we aren't ready to support them being used externally. Hopefully we can support them one day, but for now we're just starting with the client.

'one day' is not very reassuring! Improved UX is nice and all, but why would anyone migrate without getting killer performance features like the virtual file system?

Sorry! 'one day' is the best I can do for now. We'd love to do it sooner, just gotta find the time.

We think, and many of our internal users agree, that the UX alone is a worth while upgrade. Since the majority of Git repos don't actually need the performance of a virtual filesystem, the UX is the main sell for them anyway. At the very least maybe it will inspire some UX improvements in Git.

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

#438

Post by durham_meta »

bentcorner wrote: post #417
durham_meta wrote: post #332

Earlier quoted context omitted.

You should be able to `sl clone ...` your git repo into a Sapling clone and use it that way, even if the repository is not on Github. I haven't personally tried whether cloning like `sl clone /path/to/some/repo` works, but it should since we're actually using the actual git binary under the hood for clone, pull, and push.

Just to clarify, I meant that I've already cloned it via git. Can I just start using sapling with it or do I need to delete the local repo and re-clone it with sapling?

You cannot just start using sl in a git repo. You need to make a Sapling clone of it.

But you can make a Sapling clone of your local git repository, so you don't have to clone from the server again and you would get all your local work from your git repo. That might be the easiest way to try Sapling, so you don't have to delete your git checkout at all.

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

#439

Post by ezst »

nemetroid wrote: post #410
riquito wrote: post #268

Earlier quoted context omitted.

I guess you didn't start from cvs or svn, because the experience moving to git was otherworldly. If git was your first versioning system than you had to learn some concepts first, which you already internalized when you switched to Mercurial.

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.

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 unrelated purposes.

To give you a practical example, any command that takes commit(s) as argument (for checking-out, logging, rebasing, …) would be passed a `revset` in mercurial-land. Revsets are a simple DSL to address commits (by hash, lineage, topology, distance, …), which makes new commands easy to learn, and renders one third of `git help log` inadequate. Most commands that output something use templates as argument, which renders another half of `git help log` laughable.

There is nothing "natural" about the git UX, you've got to accept that it grew organically with no attention to details.

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

#440

Post by durham_meta »

Vinnl wrote: post #411
durham_meta wrote: post #332

Earlier quoted context omitted.

You should be able to `sl clone ...` your git repo into a Sapling clone and use it that way, even if the repository is not on Github. I haven't personally tried whether cloning like `sl clone /path/to/some/repo` works, but it should since we're actually using the actual git binary under the hood for clone, pull, and push.

Is that a one-way street, or can I personally adopt Sapling for our Git repos without my collaborators even noticing? (For now.)

You could personally clone a git repo with Sapling and no one would know the difference. When using Sapling with a git repo, clone, push, and pull all use the actual git binary under the hood, so the server just sees git speaking to it.
Post reply on HN