mitrandir77

Yup, it's automatic rebase of a commit on top of the newer (amended) version of its parent.

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

https://news.ycombinator.com/item?id=33615077

I don't see why merge conflicts would be a pain specific to monorepos. The merge conflict arises when you and some other person modify the same parts of the same file. No matter the repo size the correct solution here is figuring out the intention of the other person by reading their change or talking to them and deciding how to combine it with your change.

The only reason which may make merge conflicts happen slightly more often in monorepo (vs constellation of small repos) is that not having the repo cloned locally is an obstacle to make the change. So some folks won't bother contributing repo that they'd have to clone first and instead they'd file a bug to the owners.

You `sl commit` that half-done work anyway and then iterate by running `sl amend` many times until your commit is finished. In case you want to amend just part of changes us `sl amend -i`

https://sapling-scm.com/docs/commands/amend

`sl histedit` is very similar to `git rebase -i` if you're famiilar with that interface which works just fine.

Other commands useful for amending changes to previous commits:

* `sl goto --merge <hash>` - if theres no conflicts you can just switch commits with pending changes and those pending changes would be applied on top of other commit. If there are conflicts this command would fail https://sapling-scm.com/docs/commands/goto

* `sl absorb` - this automagically finds the last commit that touched the lines that are pending and amends that commit with them https://sapling-scm.com/docs/commands/absorb

Phabricator was opensourced by Facebook. But most of it life as an opensource product is was actively maintained by Phacility.

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've tried one very basic terminal rendering benchmark I had at hand [1] and on my MacBook Pro it was 17x faster than iterm and 3x faster than wezterm which is my daily driver.

https://github.com/wez/wezterm/issues/192

So it's not all that bad ;)

It is quite fast tbh and non-sluggish terminal is nice-to-have.

I've tried one terminal rendering benchmark I had at hand [1] and on my MacBook Pro it was 17x faster than iterm and 3x faster than wezterm which is my daily driver.

[1] https://github.com/wez/wezterm/issues/192