Rebasing a merge commit as the -s value - is the current "flattening" behavior intentional?

[TaoK]

Background: Why Rebasing Merges matters

Supporting a large group of developers, on a large project, with most users being relatively inexperienced with git, one of my big frustrations with that system is the way merges and rebases don't work together:

We generally recommend merging over rebasing, because branches are often shared and rebasing shared branches (where many/most users aren't rebasing experts) is a recipe for disaster. Generally, that policy ("just don't rebase unless you really know what you're doing; always default to merging") works well for us.

Occasionally however, a user will end up rebasing a previous merge of main onto another topic/feature branch, by accident because of a bad GUI, or because they don't know better. When you rebase a merge commit in git (without --rebase-merges), all the merged-in commits (in the typical flow here, all the main commits that were merged in) get rebased onto the target branch - they effectively get duplicated - which is absolutely not what you want, of course.

In git, this can be fixed-ish using --rebase-merges, which automatically recreates merge commits / attempts to replicate the merge topology when you rebase. It's not a panacea by any means because previously resolved conflicts need to be re-resolved (unless you're also using rerere are your conflicts are isolated), but it's more reasonable than the default behavior, in the scenario above, at least.

A naive rebase of a merge commit in jj "flattens" it...?

When I first tried this scenario in JJ, I found two surprises:

• A "naive" rebase of a (conflicted+resolved) merge yielded a new 3-way conflict (4-way merge? 5-way merge?), which jj resolve refused to run on, and with conflict markers that were unintelligible to me (I couldn't understand what the different bases were supposed to be)
  • I would have expected JJ's "conflicts as first-class constructs" magic to be able to auto-resolve at least part of the rebase conflict, but that was not the case
• Once I finished resolving the merge conflict, I jj squashed and jj logged, only to find that the merge commit I rebased had turned into a regular single-parent commit.

I understood later from the answers below that this outcome came about because of the way I specified the merge commit in the -s arg, and only the single new parent commit in -d, which told jj to rebase as a simple single commit; the weird 3-way conflict, I think I now understand, was jj showing me that there were two sets of parent-child changes to collapse into a new single-parent commit.

As I later noted in #3727 (comment), if the merge commit is a child of the commit provided in the -s arg, everything works as you would expect, magically wrt git.

@bnjmnt4n has noted that it is possible to specify a -d argument that specifies the right parent commit(s) for such a rebase, but it's a bit of a mouthful: #3727 (reply in thread). Can/should there be a more "natural" way of doing the equivalent of git pull --rebase=merges?

[bnjmnt4n]

What's the command you used to rebase? jj rebase -r doesn't preserve a commit's parents by default. jj rebase -s will preserve the parents of the descendants of the commit specified.

[TaoK]

OK, so, confirmed: The problem is targeting the merge commit itself in the -s arg; If I target a parent of the merge commit, then the merge commit gets rebased cleanly, as a merge commit, with no new conflicts at all! jj clearly delivers on its promises / on the hype in this case, where the merge is a descendant of what you targeted.

Is there a way to say "rebase this merge commit wrt the first parent as a merge of the second parent" when you can't target an ancestor of the merge commit or, more importantly maybe, if you don't even realize that you need to treat a merge commit differently?

[yuja]

There are no options to special-case the first parent, but you can specify multiple destinations as new parents.

jj rebase -s x -d new_first_parent -d old_second_parent

[bnjmnt4n]

Currently there's no revset syntax for specifying the exact parent commit (first/second). However, if you're rebasing say from a descendant of trunk() (or some other branch) onto the latest trunk(), you can use something like the following:

jj rebase -s X -d "all:trunk() | (X- ~ ::trunk())"

This keeps all of X's existing parents which are not a descendant of trunk(), and adds trunk() as a new parent as well.

It's a bit clunky, but this comes up quite infrequently enough that jj rebase -d trunk() works well enough for me most of the time. It's probably easier to just run look at the logs and specify each parent exactly if there's a merge commit. jj undo is also helpful if you realize a mistake after the fact.

[TaoK]

There are no options to special-case the first parent, but you can specify multiple destinations as new parents

Thanks @yuja, I guess this is approximately the same answer/outcome as @amiryal 's comment #3727 (reply in thread), you both answered in the same moment :)

Currently there's no revset syntax for specifying the exact parent commit (first/second)

Thanks @bnjmnt4n for the confirmation - I searched for this but could not find it, now I know why :)

However, if you're rebasing say from a descendant of trunk() (or some other branch) onto the latest trunk(), you can use something like the following

I tried this (in my context creating a feature-merged branch, and then running jj rebase -s feature-merged -d "all:feature | (feature-merged- ~ ::feature)"), and it seemed to do the same as jj rebase -s feature-merged -d feature -d master, although I can't claim to understand how...

But anyway, thanks, this looks like it was effective magic!

[TaoK]

With my new improved-but-still-awful understanding of jj workflows, I think my big question now is:

• Given a "feature branch", origin/feature on which multiple members of a team are working, and
• A "main branch" that lots of teams merge to
• A team member who's been tasked with "merging down" from origin/main to the feature branch, and
• Their having completed that task, (as one or more commits, maybe a merge and a couple fixups), and
• Their getting a push conflict when trying to push the resulting new commits (because another team member got there first with an unrelated change), and
• Their choosing to use Rebase, rather than Merge, to make their local work pushable...

Is there / can there be / should there be a reasonable invocation for them to achieve that last step?

in git, that scenario goes like:

git clone git@github.com:TaoK/integration-down-flow-test.git
cd integration-down-flow-test
# simulating a race between team members...
git update-ref refs/remotes/origin/feature origin/feature~
# regular flow
git checkout feature
git merge origin/master
# resolve conflicts & commit
git mergetool && git commit
git push # get an error: push conflict
git pull --rebase=merges
# resolve conflicts & finish rebase
git mergetool && git rebase --continue
git push

in jj, with @bnjmnt4n's proposal, I understand I would do the same thing as follows:

git clone git@github.com:TaoK/integration-down-flow-test.git
cd integration-down-flow-test
# simulating a race between team members... I can't figure out how to do this in jj so dropping into git
git update-ref refs/remotes/origin/feature origin/feature~
jj git init --colocate
jj branch track feature@origin
# merging master into (a slightly outdated) feature
jj new feature master@origin
# resolve conflicts & commit
jj resolve
jj commit -m "Merge master into feature"
jj branch set feature -r @-
jj git push # get an error: push conflict
jj git fetch
jj rebase -s feature@git -d "all:feature@origin | (feature@git- ~ ::feature@origin)"
jj git push

So, the equivalent of git pull --rebase=merges (without needing to eyeball a jj log history and pick out a specific change ID, and without needing to think about whether the first commit/change they are going to end up rebasing happens to be a merge commit) might be something like:

CURR_BRANCH=feature
jj git fetch
jj rebase -s $CURR_BRANCH@git -d "all:$CURR_BRANCH@origin | ($CURR_BRANCH@git- ~ ::$CURR_BRANCH@origin)"

Is there any way to turn this last line into some sort of alias?

Would it be reasonable to "request"/suggest the introduction of some porcelain facility for this operation / this flow? How would one go about doing such a thing?

I would think a reliable and simple flow for "I did some work locally, and I want to push it to the shared branch on the server now, without introducing yet another merge", would be a sensible thing to request/provide?

(as my understanding has evolved, I've tried to update the main question in this discussion to make sense)

[TaoK]

My complete "failing" repro script is:

git init test-repo
cd test-repo
cat | git fast-import << EOF
blob
mark :1
data 14
a
b
c
d
e
f
g

reset refs/heads/feature-merging
commit refs/heads/feature-merging
mark :2
author Klerks, Tao <tao.klerks@oracle.com> 1716277583 +0200
committer Klerks, Tao <tao.klerks@oracle.com> 1716277583 +0200
data 15
Initial Commit
M 100644 :1 File1

blob
mark :3
data 24
a
b changed 1
c
d
e
f
g

commit refs/heads/master
mark :4
author Klerks, Tao <tao.klerks@oracle.com> 1716277677 +0200
committer Klerks, Tao <tao.klerks@oracle.com> 1716277677 +0200
data 10
changed 1
from :2
M 100644 :3 File1

blob
mark :5
data 34
a
b changed 1
c
d changed 2
e
f
g

commit refs/heads/master
mark :6
author Klerks, Tao <tao.klerks@oracle.com> 1716277712 +0200
committer Klerks, Tao <tao.klerks@oracle.com> 1716277712 +0200
data 10
changed 2
from :4
M 100644 :5 File1

blob
mark :7
data 44
a
b changed 1
c
d changed 2
e
f
g changed 3

commit refs/heads/master
mark :8
author Klerks, Tao <tao.klerks@oracle.com> 1716277731 +0200
committer Klerks, Tao <tao.klerks@oracle.com> 1716277731 +0200
data 10
changed 3
from :6
M 100644 :7 File1

blob
mark :9
data 27
a
b
c
d
e
f
g
h added some

commit refs/heads/feature-merging
mark :10
author Klerks, Tao <tao.klerks@oracle.com> 1716277851 +0200
committer Klerks, Tao <tao.klerks@oracle.com> 1716277851 +0200
data 11
added some
from :2
M 100644 :9 File1

blob
mark :11
data 46
a
b
c
d changed separately
e
f
g
h added some

commit refs/heads/feature-merging
mark :12
author Klerks, Tao <tao.klerks@oracle.com> 1716277908 +0200
committer Klerks, Tao <tao.klerks@oracle.com> 1716277908 +0200
data 13
changed some
from :10
M 100644 :11 File1

blob
mark :13
data 64
a
b
c
d changed separately
e
f
g
h added some
i added some more

commit refs/heads/feature
mark :14
author Klerks, Tao <tao.klerks@oracle.com> 1716277952 +0200
committer Klerks, Tao <tao.klerks@oracle.com> 1716277952 +0200
data 16
added some more
from :12
M 100644 :13 File1
EOF

jj git init --colocate

jj new feature-merging master

jj resolve #resolve conflict

jj commit -m "Merge master into feature but jj doesn't default the message."

jj rebase -s @- -d feature

# already `jj log` here shows me the rebased conflicted changeset with only one parent, feature

# manually resolve

jj squash

(my apologies for the script length / the fast-import - this is a repro case I have been reusing across multiple configurations and clients)

[amiryal]

In your final jj rebase -s @- -d feature, if I understand correctly, what you really want instead is:

jj rebase -s @- -d feature -d master

I.e. you need to spell out to jj explicitly all the parents you want the rebased commit to have with multiple -d.

[TaoK]

OK, that works - so the "rule of thumb" that I would need to internalize, to get behavior equivalent to git rebase --rebase-merges (but an outcome superior in several ways :) ), sounds like it might be something like If you are rebasing a merge commit as the -s value in jj, then you need to explicitly specify all the "other parents".

In the git formulation, the "parent I am rebasing from" is implicit, and so the "other parent" (in the case of git --rebase-merges feature) is inferred...

Is there an equivalent to the git formulation, saying something like "take my changes (including merges) wrt feature and rebase them onto feature"?

I tried jj rebase -d feature, but that ends up with a substantially different "merge topology" and a different, more straightforward, 2-way conflict... vs jj rebase -s @- -d feature -d master which just completes cleanly with no conflict at all, and with the final topology I would have expected from git --rebase-merges feature. :(

EDIT: my question seems to be mostly answered in another thread #3727 (reply in thread), above, so retracting this one.

[TaoK]

For comparison, the following script, where there is an extra unrelated commit before the merge, and that previous commit is the thing we ask to rebase, works cleanly - jj does exactly what I would have expected and it's beautiful:

# INCLUDE THE PREVIOUS SCRIPT up to the "EOF"

git checkout feature-merging

sed -i 's/^a$/a changed/' File1

git add .

git commit -m "unrelated change"

jj git init --colocate

jj new feature-merging master

jj resolve #resolve conflict

jj commit -m "Merge master into feature but jj doesn't default the message."

jj rebase -s feature-merging -d feature