[arxanas]

> I wonder how this behave if commits get randomly pushed to origin

You would expect the push to fail in the normal way, as if you had manually done the rebase, because your commit history may have diverged. That being said, I don't think this happens much in practice: the automatic rebases are typically for explicit history-rewriting operations that users tend to only do on their local work. If a user prefers to use a "no-rewriting" workflow, then they can certainly do so by simply not issuing the history-rewriting commands.

> anonymous branches are destined to be pushed remotely (to be reviewed and merged) and there is no local merge as far as I can tell, you can name these branches but no "merge back to development branch once done".

I'm not sure what you mean by this. You can do `jj merge` in a similar way to `git merge`, or you can do a rebase workflow.

[Manjuuu]

> You would expect the push to fail in the normal way, as if you had manually done the rebase, because your commit history may have diverged. That being said, I don't think this happens much in practice: the automatic rebases are typically for explicit history-rewriting operations that users tend to only do on their local work. If a user prefers to use a "no-rewriting" workflow, then they can certainly do so by simply not issuing the history-rewriting commands.

Yeah, most of those rebases happen in the working copy or inside the anonymous branch.

> I'm not sure what you mean by this. You can do `jj merge` in a similar way to `git merge`, or you can do a rebase workflow.

I just meant merging a feature branch back to its parent, jj merge exists but it's not obvious which revisions you are supposed to pass to it and jj log doesn't even seem to be able to update the HEAD for the parent branch. It should be an easy operation but it's not, clearly not the suggested workflow (or at least, not documented from what I've read).

[arxanas]

> jj merge exists but it's not obvious which revisions you are supposed to pass to it

I don't think I understand your confusion. `jj merge` is essentially like Git merge, except that you also normally pass the current commit as one of the revisions. For example, you could write `jj merge @ main` to make a merge commit with the working copy[1] and the `main` branch. Feel free to open a GitHub discussion or drop by the Discord channel to discuss more.

> jj log doesn't even seem to be able to update the HEAD for the parent branch

`git log`/`jj log` are non-mutating operations, so why would you expect that they can update `HEAD`/branches?

[1]: In my workflows, I typically use `@-` instead of `@` in this situation because I consider the working copy commit to contain "uncommitted" changes, but there is a significant complement of users who primarily use `@`, so it depends on your workflow.

[Manjuuu]

Thanks for the detailed answer.

> For example, you could write `jj merge @ main` to make a merge commit with the working copy[1] and the `main` branch.

Since it's my first time seeing this, the syntax is a bit confusing, the man says "Unlike most other VCSs, `jj merge` does not implicitly include the working copy revision's parent as one of the parents of the merge; you need to explicitly list all revisions that should become parents of the merge.", it's not clear to me if the order matters and how many can be listed (and why for more than 2). What I wanted to replicate was just doing a "git co main; git merge feature-branch", thanks for the explanation.

> git log`/`jj log` are non-mutating operations, so why would you expect that they can update `HEAD`/branches?

What I meant was that with git status/log the differences between your local clone and the remote are clearly shown, you know if they are misaligned and see the last commit for each branch without using additional commands, jj log/st provide way less info. I see where "main" is in jj log but have no idea if that label will update after a push or a fetch of the remote. Just a bit confusing for newcomers, I have to play with it.

[arxanas]

> 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.