5 ms·

To use a similar featureset but in the same Git repository you normally use, you can try my https://github.com/arxanas/git-branchless https://github.com/arxanas

To use a similar featureset but in the same Git repository you normally use, you can try my https://github.com/arxanas/git-branchless 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, such as interactive undo? Jujutsu also supports colocated Git repositories: https://github.com/martinvonz/jj https://github.com/martinvonz/jj. It also has the working-copy-as-a-commit idea and conflicts are stored in commits (so rebases always succeed). I think it's a step forward compared to git/hg/sl.

kbd 4y ago
I'm glad you mentioned Jujutsu. Given that it's also a git-compatible SCM my first thought upon seeing this post was how Sapling and Jujutsu compare.
- martinvonz 4y ago
  I think those two things that arxanas mentioned are the biggest differences (i.e. working-copy-as-commit and conflicts in commits). I haven't used Sapling, but I suspect Jujutsu has better support for moving commits (and parts of commits) around without touching the working copy. Sapling, on the other hand, has much better support very large repositories, since they've spent a lot of time on that over the years. We're going to copy some of Sapling's solutions to Jujutsu soon, since we're working on integrating it with Google's monorepo (slides: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX_L4bQ9NMcYOp1isn17kTC_M/edit#slide=id.g152b1fb8869_0_1432 https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX..., recording: https://youtu.be/bx_LGilOuE4 https://youtu.be/bx_LGilOuE4).
  - martinvonz 4y ago
    Oh, in the context of Sapling, I should say that Jujutsu runs the equivalent of `sl restack` after every command. Thanks to first-class conflicts, that always works.
  - arxanas 4y ago
    Yep — after trying out Sapling, it aborts many operations due to working copy changes, which I now find to be jarring interruptions to my workflow. Jujutsu (and even git-branchless) have much better support for juggling working copy changes, which is invaluable in a patch-stack workflow. The Sapling support for remote repositories was a little rough in my opinion. Jujutsu and git-branchless can both co-locate with the Git repository, so you can always drop down to Git commands if there's something you're having trouble doing. (I find the `jj git` commands to also be better at interacting with remotes for now.)
  - ironfootnz 4y ago
    I see a few issues on their approach for working copy and log search. Let me try out and see if I'm right on my assumptions.
zamalek 4y ago
> conflicts are stored in commits (so rebases always succeed) Is this pushed to the remote when running as a git porcelain?
- martinvonz 4y ago
  No, the CLI prevents that because the remote is unlikely to know how to interpret conflicts. In a future where the remote understands conflicts, then you'll be able to push conflicts to a remote and collaborate on the conflict resolution.
  - zamalek 4y ago
    Ah that's a pity, but totally understandable.
tome 4y ago
> 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 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 https://news.ycombinator.com/item?id=33617689
- arxanas 4y ago
  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.
  - tome 4y ago
    > > Looks like it calls out to the git executable occasionally > > I believe Jujutsu never calls out to Git Oh, I was referring to Sapling. I know even less about Jujutsu than I do about Sapling! > > presumably works on the git object model under the hood > > There's no guarantee of this ... but they reserve the right to change that Interesting. So it would translate between them whenever you push to or pull from a Git repo? I'm very keen to use Sapling if it's basically a polished interface to Git but less keen if it's an entirely different object model, because then I'm going to have to learn more about what's going on under the hood to understand it properly.

kbd 4y ago

I'm glad you mentioned Jujutsu. Given that it's also a git-compatible SCM my first thought upon seeing this post was how Sapling and Jujutsu compare.

martinvonz 4y ago
I think those two things that arxanas mentioned are the biggest differences (i.e. working-copy-as-commit and conflicts in commits). I haven't used Sapling, but I suspect Jujutsu has better support for moving commits (and parts of commits) around without touching the working copy. Sapling, on the other hand, has much better support very large repositories, since they've spent a lot of time on that over the years. We're going to copy some of Sapling's solutions to Jujutsu soon, since we're working on integrating it with Google's monorepo (slides: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX_L4bQ9NMcYOp1isn17kTC_M/edit#slide=id.g152b1fb8869_0_1432 https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX..., recording: https://youtu.be/bx_LGilOuE4 https://youtu.be/bx_LGilOuE4).
- martinvonz 4y ago
  Oh, in the context of Sapling, I should say that Jujutsu runs the equivalent of `sl restack` after every command. Thanks to first-class conflicts, that always works.
- arxanas 4y ago
  Yep — after trying out Sapling, it aborts many operations due to working copy changes, which I now find to be jarring interruptions to my workflow. Jujutsu (and even git-branchless) have much better support for juggling working copy changes, which is invaluable in a patch-stack workflow. The Sapling support for remote repositories was a little rough in my opinion. Jujutsu and git-branchless can both co-locate with the Git repository, so you can always drop down to Git commands if there's something you're having trouble doing. (I find the `jj git` commands to also be better at interacting with remotes for now.)
- ironfootnz 4y ago
  I see a few issues on their approach for working copy and log search. Let me try out and see if I'm right on my assumptions.

zamalek 4y ago

> conflicts are stored in commits (so rebases always succeed) Is this pushed to the remote when running as a git porcelain?

martinvonz 4y ago
No, the CLI prevents that because the remote is unlikely to know how to interpret conflicts. In a future where the remote understands conflicts, then you'll be able to push conflicts to a remote and collaborate on the conflict resolution.
- zamalek 4y ago
  Ah that's a pity, but totally understandable.

tome 4y ago

> 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 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 https://news.ycombinator.com/item?id=33617689

arxanas 4y ago
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.
- tome 4y ago
  > > Looks like it calls out to the git executable occasionally > > I believe Jujutsu never calls out to Git Oh, I was referring to Sapling. I know even less about Jujutsu than I do about Sapling! > > presumably works on the git object model under the hood > > There's no guarantee of this ... but they reserve the right to change that Interesting. So it would translate between them whenever you push to or pull from a Git repo? I'm very keen to use Sapling if it's basically a polished interface to Git but less keen if it's an entirely different object model, because then I'm going to have to learn more about what's going on under the hood to understand it properly.