FR: mechanism to create a merge commit that treats one revset as equivalent to another one

[zygoloid]

Is your feature request related to a problem? Please describe.
Here's the situation:

• Create a development branch, add some commits there, say aa::bb- that make a series of changes to a file F.
• Create github PR A for that branch.
• Create a dependent branch, add some commits there, say bb::cc that also change file F.
• Create github PR B for that second branch.
• PR A is squash-merged into a new commit; let's say it imports back into jj as dd. This creates a conflict for B in file F.
• I now want to create a merge commit on B to merge the trunk change. (Rebase is a no-go because it breaks github's review comment tracking.)

Describe the solution you'd like
I would like some way to create a merge commit where I inform jj (or it works out) that aa:bb- got squashed into dd, so that I don't need to manually resolve "conflicts" in file F (there are no real conflicts, only confusion caused by the same edits being made on the two sequences of revisions).

Describe alternatives you've considered
There seems to be a range of potential approaches:

• Some way to tell jj that dd intends to make the same changes as aa:bb- (and can be cancelled out when performing jj's diff algebra). Then simply jj new cc trunk should be enough.
• Make jj detect that the state of file F is identical in aa and dd-, and is identical in bb- and dd, and so cancel out aa:bb- with dd automatically. (Con: only works if there were no other changes to F on trunk in the interim.)
• Check whether any subsequence of the edits to F on trunk matches any subsequence of edits to F on the branch to dd and cancel those out. (Con: It's not clear to me that there's a < quadratic-time way to do that. But if we assume that we only want to cancel a single-revision change against a range of revisions, there are probably some reasonable heuristics. For example, you can find the first revision that removes a "distinctive" line removed in dd and the last revision that adds a line added in dd, and check whether that range is equivalent to dd.)
• Like the first approach, but add a configuration setting where I can specify a hook to compute equivalent change series, so that I can parse the (#1234) that github adds to the commit message, and find the equivalent commits from the pull/1234/head branch.

[josephlou5]

Just for my own sake, could you confirm that this is your situation? My understanding is:

# Initial
$ jj log
○  qqq (cba987) github-pr-B
│  The second PR
○  ppp (def456) github-pr-A
│  The first PR
◆  xyz (abc123) main
│  The trunk
~

# After first squash merge and a fetch
$ jj log
◆  rrr (c93a7d2) main
│  The squash merge of PR A (#123)
│ ○  qqq (cba987) github-pr-B
│ │  The second PR
│ ○  ppp (def456)
├─╯  The first PR, whose bookmark was deleted maybe
◆  xyz (abc123)
│  The old trunk
~

And now you want to do jj new rrr qqq and move github-pr-B to that merge, so that the commit ID of github-pr-B doesn't change to preserve your GitHub review comments. However you're getting conflicts, despite rrr having the same content as ppp (or whatever was squashed). Does that sound right?

(Also would love a way to do this "properly" as well!)

[zygoloid]

That's the distilled essence of it, yes.

My actual situation had commits between xyz and rrr, and both ppp and qqq were a series of commits touching the same file, not a single commit. I think there were also commits between rrr and main. (I mention this because a solution that merely identifies that ppp and rrr are rebased versions of the same change wouldn't work for me, but might work for a rebase-merge workflow -- and is probably much easier than what I'm asking for!)

[josephlou5]

Yeah sorry for simplifying a ton lol, didn't feel like doing lots of mock graphs :p But yeah squash merge seems to not be super well supported ATM, so I'm glad for this issue.