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

471–480 of 543 posts

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

#471

Post by trilobyte »

durham_meta wrote: post #442
trilobyte wrote: post #435

Earlier quoted context omitted.

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.

Because we haven't released the server yet, the open source client currently only really supports git right now, so sl init --git is the only way to init a local repo for now. Perhaps we could make that message clearer. I'll take a look at the help later to see what we're missing here.

Cool, thanks for the reply. It definitely threw me off and if it only supports git as a backend for the open source user it might make sense if it can default that way for now.

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

#472

Post by tome »

ArchOversight wrote: post #37

I use the staging area to allow me to more easily break larger changes into smaller commits. I am usually all over the place while writing/refactoring code and making commits as I go along doesn't work well. How does sapling let me take a long list of commits and break them into larger but more manageable chunks? git add -p allows me to add chunks easily and create commits, git commit --fixup allows me to mark a comm…

> I use the staging area to allow me to more easily break larger changes into smaller commits ... git add -p allows me to add chunks easily

Sure, but you can use `git commit -p` to get the same benefits without explicitly using the staging area.

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

#473

Post by tome »

arxanas wrote: post #27

To use a similar featureset but in the same Git repository you normally use, you can try my https://github.com/arxanas/git-branchless . Then, you can use your usual staging workflows if desired, or use regular Git commands directly. Its design is inspired by Sapling, and, in fact, it uses some of the same code, such as the segmented changelog implementation. Possibly some of its ideas made their way back to Meta, suc…

> To use a similar featureset but in the same Git repository you normally use

What do you mean? Can't you use Sapling in the same Git repository you normally use? The first sentence is "Sapling is a new Git-compatible source control client". Is there something they're not telling us?

EDIT: Looks like it calls out to the git executable occasionally (https://news.ycombinator.com/item?id=33615576) and presumably works on the git object model under the hood, but you can't use `git` on a repo checked out using `sl` nor vice versa. It's a stretch to call it Git-compatible but I guess not completely wrong.

EDIT2: Here's a good summary https://news.ycombinator.com/item?id=33617689

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

#474

Post by tome »

lijogdfljk wrote: post #31
mitrandir77 wrote: post #19

Earlier quoted context omitted.

It's simply not necessary to have that feature. Sapling encourages regularly committing and amending commits rather than staging changes. It's also easy to commit / amend part of your work by selecting the lines to include in nice curses interface (--interactive).

I agree it's not necessary, but i like having it because it lets me separate what's going to be added before i actually commit. I still commit small, frequent. But i like `git add -p` to skip debug lines, hardcoded conditions, etc. I don't want to mistakenly auto commit a whole pile of lines and then have to remove debugs/hacks/etc from things i've committed. Stage + Unstaged is my working area, and the two live toge…

> But i like `git add -p` to skip debug lines, hardcoded conditions, etc

You can use `git commit -p` to get the same functionality but without explicitly using the staging area.

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

#475

Post by tome »

ISL wrote: post #62
mitrandir77 wrote: post #19

Earlier quoted context omitted.

It's simply not necessary to have that feature. Sapling encourages regularly committing and amending commits rather than staging changes. It's also easy to commit / amend part of your work by selecting the lines to include in nice curses interface (--interactive).

How do you construct a commit, in order to commit regularly, without having a staging environment in which to compose that commit? Is the branch-tip simply the staging area? What if you're only half-done with that final commit?

> How do you construct a commit, in order to commit regularly, without having a staging environment in which to compose that commit?

In git, with `git commit --patch`

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

#476

Post by tome »

still_grokking wrote: post #419
guytv wrote: post #401

Earlier quoted context omitted.

Isn't the staging area just a stack of changes where stack height == 1?

Sure. And a branch is also just a stack of changes… The whole point is that this things are treated differently.

But a branch is a commit but the staging area is an index, which is something different. Why two different concepts when one would do? That's my problem with the staging area.

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

#477

Post by ezst »

kyrra wrote: post #276
mitrandir77 wrote: post #183

Nobody commented on the web interface yet which I think it's one of our coolest features: https://sapling-scm.com/docs/addons/isl

I'm sort of amazed that git and mercurial haven't built something like that yet. Makes me a little sad that Facebook created a new scm instead of expanding mercurial to include features like this.

just type `hg serve` and that will spin-up a web UI like this one:

https://www.mercurial-scm.org/repo/hg/graph/tip

, seems to have been included since 2005 :)

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

#478

Post by tome »

arxanas wrote: post #353
sixstringtheory wrote: post #347

Earlier quoted context omitted.

> how do you split the contents of the staging area into two separate groups What is the workflow behind this ask? I don't understand what the goal is. The basic git workflow: 1. Edit and save a tracked file; the changes appear in the working tree. 2. Select some subset of the changes in the working tree to stage them in the index. 3. Form a commit with the changes in the index. IIUC you want to add a step in between…

To accomplish your workflow, there doesn't seem to be any need for a staging area at all. You can use an interactive commit selector to stage a subset of changes (or select a set of changes some other way), and then if you want to keep adding/"staging" changes, you can amend the commit you just made. Occasionally, I do run into the situation where I've staged some changes and then realize that I want to start staging…

> You can use an interactive commit selector

... such as `git commit --patch`, which this discussion has taught me many people don't know about, even those who know about `git add --patch`.

(I was one such person a few years ago until my mind was blown by an HN commentor doing me the same favour as I have done here :) .)

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

#479

Post by Vinnl »

durham_meta wrote: post #440
Vinnl wrote: post #411

Earlier quoted context omitted.

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.

That's great, looking forward to giving it a shot!

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

#480

Post by arxanas »

tome wrote: post #473
arxanas wrote: post #27

To use a similar featureset but in the same Git repository you normally use, you can try my https://github.com/arxanas/git-branchless . Then, you can use your usual staging workflows if desired, or use regular Git commands directly. Its design is inspired by Sapling, and, in fact, it uses some of the same code, such as the segmented changelog implementation. Possibly some of its ideas made their way back to Meta, suc…

> To use a similar featureset but in the same Git repository you normally use What do you mean? Can't you use Sapling in the same Git repository you normally use? The first sentence is "Sapling is a new Git-compatible source control client". Is there something they're not telling us? EDIT: Looks like it calls out to the git executable occasionally ( https://news.ycombinator.com/item?id=33615576 ) and presumably works…

What I mean is that you can't co-locate your Sapling repository with your Git repository (at least, for now). You have to have them in separate directories and push/pull between them.

git-branchless is only an extension to Git, so it naturally operates in the Git repository. Jujutsu has a mode to create the `.jj` directory alongside the `.git` directory and co-locate them, which I find very convenient in practice. (Originally, Jujutsu only supported Git compatibility in the same way as Sapling, via pushes and pulls, but they added co-location later.)

> Looks like it calls out to the git executable occasionally

I believe Jujutsu never calls out to Git, and that all of its `jj git` interop commands are implemented via direct bindings to libgit2. This is less fragile in many ways, but it can also mean that `jj git` interop might be missing some new feature from Git. Fortunately, you can oftentimes just run the Git command directly in the repository when co-locating.

> presumably works on the git object model under the hood

There's no guarantee of this: the Mercurial (and therefore possibly Sapling?) revlog model is a little different from the Git object model, as I understand it. But it doesn't really matter, as long as it interoperates seamlessly. For now, I believe they do literally have a `.git` directory somewhere under the `.sl` directory, but they reserve the right to change that.

Post reply on HN