[aseipp]

Google currently uses a fork of Mercurial as the frontend to Piper, but there is work to replace it wholesale, eventually: https://github.com/martinvonz/jj

(As a disclosure, I'm involved with and contribute to jj, but I don't work for or speak for Google in any way; the above statement is public knowledge.)

[culi]

Any comments about what it does better than git and mercurial?

[plorkyeran]

The big idea that excites me is that it does away with the concept of having uncommitted changes. Instead, every time you save a file in a repository it is automatically committed. It is the logical endpoint of the git workflow where you make lots and lots of little wip commits and then rewrite them into a sensible set of commits later, and the whole UI is designed around making that work well rather than being something that works but constantly feels like it's off the intended path.

[aseipp]

I completely rewrote the README recently to be more "user friendly"; does it address some of your question? I'm not trying to be snarky, I'm genuinely interested in if the README is now tantalizing enough to make you interested: https://github.com/martinvonz/jj?tab=readme-ov-file#introduc...

But in short, it has a better UX than Git by a mile while remaining interoperable at the storage level, so you can use GitHub; it has many of the niceties of Mercurial's UX like revsets, no staging area, and a templating language for log output. Conflict resolution and rebasing is clean, easy, and nearly automatic. It has features neither support, like a real undo command and "operation log"[1]. The UX is smaller and conceptually cleaner; fewer "verbs" that operate on less "nouns", so many things are more regular. It is available as an API (Rust crates) so you can extend it naturally to handle your own workflow, without monkey-patching things. You could even use Mercurial itself as a storage backend, or a custom, centralized server like Google does.

Most importantly though, its internal "automatic snapshot model" design is quite elegant and makes the design and internals very clear. And storage system is completely independent and abstracted from this, and many of the other algorithmic details (Git sort of intertwines the data model, the algorithms, and the UX in various ways.) Features like hg changeset evolution, git rerere, and rebase --update-refs are all obsoleted and naturally handled by this design, among other things.

Martin, the lead developer, also had a talk at Git Merge 2022 that covers many of the fundamentals. They're all still the same but we're evolving many things rapidly: https://www.youtube.com/watch?v=bx_LGilOuE4

[1] Yes I know about the reflog, no it is not equivalent! It only tracks changes made to visible references ("ref" "log") while jj's oplog actually tracks commands invoked, and lets you completely undo individual things in the blink of an eye, or rewind if you wish.

[marwis]

Lack of staging area kind of sucks. I'd prefer the opposite - having multiple staging areas (like IntelliJ chabgelists) so I can incrementally build multiple changes at the same time.

Is there anything in jj that could be used as a substitute?

[plorkyeran]

`jj split` and `jj move` are the equivalent of git's staging areas. Instead of picking which changes you want to commit, you pick which changes you want to move from the working-copy commit to the target commit you're assembling. It lets you do something very similar to multiple staging areas by having multiple commits that you're moving changes to.

[marwis]

This sounds reasonable but I'd like to somehow distinguish these work-on-progress commits. Is there an equivalent of mercurial commit phases?

[aseipp]

Like the parent said, you typically let the "automatic working copy commit" take the place of the staging area. Really, the staging area still exists in some sense, but it's not a distinct "thing" in the UX; rather than being represented by a unique name in the tool's lexicon (the "index"), it's just represented by another commit. So, you slice and dice that commit, as you see fit.

Similarly, there is no concept of stash. The working-copy-commit model removes the need for a distinct "stash" verb, just like it removes the need for the "index" noun.

(In Git, stashes and the staging area are of course trees of blobs, just like ordinary commits. It's just that the UI surfaces them as distinct nouns.)

> This sounds reasonable but I'd like to somehow distinguish these work-on-progress commits. Is there an equivalent of mercurial commit phases?

There isn't any current notion of phases right now, but we've thought of adding them. At the moment, the main distinction added recently is between "immutable" commits and mutable ones, which is determined by a revset, and that revset by default is something like "Anything published on or an ancestor of a head in the remote." Immutable commits cannot be rewritten to a new commit ID.

Frankly I just tag all of my work-in-progress commits with 'wip:', and I use a revset to select and look through every change authored by me that isn't located in the remote main branch.

We are also thinking about improving the color and iconography of the default output to make immutable vs mutable more distinct. So we're not sure if we even need phases yet, I think...

[KingMob]

Personally, I like the elimination of staging and stashing. These always seemed like unnecessarily separate concepts.

But what I'm most interested in exploring is support for first-class conflicts. I hate the weird state of existing git conflict resolution.