| > it's not clear to me if the order matters and how many can be listed It's worth noting that in Git, 1) the order is recorded and tracked in the commit (but almost always doesn't matter), and 2) you can have any number of parents for a commit. A >2-parent commit is called an "octopus merge" in Git, which you can search further to learn about. Thus, the only real difference is that Git defaults to including the current commit as one of the merge parents (and this can't really be disabled via `git merge` itself; you'd have to use one of the plumbing commands and construct the commit manually). In Git, you can have 0+ parent commits; in Mercurial, you can have 0-2 parent commits; in Jujutsu, you can have 1+ parent commits (except for the special root commit with the zero hash, which is the ancestor of all commits that would otherwise have no parents). To explicitly answer about the merge parent order, you can see a question like this: https://stackoverflow.com/q/49715421/344643. I suspect that under jj the difference is not nearly as complicated because of how it records conflicts, but I don't know for certain. > What I meant was that with git status/log the differences between your local clone and the remote are clearly shown In general, the multi-remote visualization could be improved in jj to handle some common workflows. You can customize the default `log` by setting `revset.log` https://github.com/martinvonz/jj/blob/7751cea47cfe6dd9654275... to show the commits you care about. If the same branch exists on multiple remotes pointing to different commits, then I believe they're rendered with the remote to disambiguate as e.g. `main@origin`. This originates from Mercurial. |