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

I don't doubt the UX is better, but internal users are a captive audience. I imagine most developers will not think twice about what vcs they are using unless their organization makes the change.

thanks for the reference, using `git-fixup` myself since years: https://github.com/keis/git-fixup

Will try `git-absorb`.

Making committed history disappear isn't something I would call a "simple action". That's something that is almost never needed.

The common case it to amend mistakes. Git makes it very easy to accomplish that.

The other thing is: Git is conceptually very simple. There are almost no "esoteric" concepts. It's just a Merkle tree and some pointers to nodes on top of a very simple plain-text database.

My experience with people that have problems to understand Git is that most of the time those people never tried to understand how Git actually works. But everything (besides the concrete commands and switches, oc) becomes almost obvious when knowing the inner workings.

The main problem with Git is its UX.

I don't know anything of this stuff out of the top of my head! I have to look up the concrete commands or switches every time. But from the conceptual point of view Git is very easy to use. Because the underlying concepts are indeed so simple and straight forward.

> Not really. I'm not sure I want it to behave the way GP suggests, but I definitely want to have staging

So I'm replying to OP's very specific usage pattern, and you object with a completely different usage pattern?

> `git commit -a` is basically an equivalent of having no staging.

GP doesn't use the staging as a staging, since they immediately stage all modified files. That means the staging is useless, they can just commit files straight from modified. Which is what `git commit -a` does.

> 1. In the vast majority of cases there are multiple files I want to commit together. Usually I change them multiple times during the process.

OK? `git commit -a` doesn't preclude that. You just use it instead of `git commit`.

> 2. It almost always starts with some debugging in a couple of other files, and I often want to keep that debugging for a couple of next commits, but `git checkout HEAD` these files in the end.

I'm really happy for you. It doesn't work when the files are already staged, which is the case of GP.

> 3. For me, the most popular way of using git rebase → edit (which I do reasonably often) is splitting a commit into 2 by separating files. This is easy enough by just changing a status of a file from "staged" to "modified" (I even have `git unstage` alias for that) and commiting.

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

> uncommit part or all of the current commit

You don't need a staging area to craft commits, you can manipulate the tip commit directly. With good enough support for that (which sapling seems to have inherited from mercurial), the staging is just an unnecessary pseudo-commit.

> What did you find appealing/unappealing?

The entire CLI is badly designed, with highly non-orthogonal commands interacting in unexpected ways. Recent versions of git has started introducing commands with a more top-down design (e.g. git switch), but that's a very novel development

Git also diverged significantly from the SVN command line, but instead of following the tasteful Darcs path of making commands clearer and cleaner it commonly:

- reused the same terms for different operations, usually less intuitive ones (e.g. the absolutely awful "git revert")

- removed clear commands to confusingly tack them onto others (e.g. "git add" to resolve commits)\

On that front, mercurial extended the existing commands-set much more cleanly and clearly.

Mercurial's CLI felt like an improved extension of SVN's, Darcs felt like a drastically different take with plenty for it, Git's felt like one of those ransom letters cut out of newspapers, full of jangly bits which make little sense, and concepts which worked fine altered for no perceivable reason.