FR: Absorb should also work when target is ahead of source

[anka-213]

Description

I would like to also be able to absorb something from an older commit into a newer one rather than only the reverse.

I can currently express my intent using

jj absorb -f older-commit -t newer-commit

However, that currently just returns "nothing changed", regardless of input. The reverse

jj absorb -f newer-commit -t older-commit

works as expected.

Steps to Reproduce the Problem

1. Make a commit
2. Make another commit that touches the same line
3. jj absorb -f older-commit -t newer-commit

Expected Behavior

The changes should be absorb into the newer commits, just like it does when the target is older than the source.

Actual Behavior

"Nothing changed."

Specifications

• Platform: Linux
• Version: jj 0.43.0

[anka-213]

I don't know of any good workaround, other than manually resolving the merge conflicts, since if I would reorder the two commits, the overlapping lines are guaranteed to cause a merge conflict.

I also don't know if this should've been a feature request or a bug report. It's probably not technically a bug, but at the same time, it's unexpected behavior from pre-existing syntax.

[yuja]

We'll need an annotation mechanism that traverses descendants in reverse order. It's a complex feature.

If the destination is a single commit, you can manually select the source hunks by jj squash -i.

[anka-213]

My specific use case was a commit which consisted of repo-wide application of automatic lint resolution and another commit ahead of that, which I wanted to move below the lint-commit. So jj squash -i wouldn't work well in that case. Resolving the conflicts was easier.

Would it be possible to reuse the annotations from the forward order and then only reverse the application? Maybe it might even be possible to emulate it user-space (without modifying jj) by first doing the forward fixup, then taking the diff from the evolog and applying the reverse of that diff to the newer commit?

But I guess the general case of multiple targets wouldn't be as simple to reverse.

[yuja]

My specific use case was a commit which consisted of repo-wide application of automatic lint resolution and another commit ahead of that, which I wanted to move below the lint-commit. So jj squash -i wouldn't work well in that case. Resolving the conflicts was easier.

If squash results in conflicts, absorb in the same direction will also produce conflicts. The key difference is that absorb automatically selects destinations to "squash" into.

Would it be possible to reuse the annotations from the forward order and then only reverse the application?

No. We'll need a view of descendant lines at the source parent, not at the destination head. Oh, but if you can rebase the source commit to destination cleanly, you can absorb changes from there.

[anka-213]

If squash results in conflicts, absorb in the same direction will also produce conflicts. The key difference is that absorb automatically selects destinations to "squash" into.

No, I meant that rebase (reordering the two commits) resulted in conflicts. Squash would in principle work fine, but I don't want to look through 100s of files to find what the conflicting lines are. So the easier solution was to just reorder them and manually resolve the conflicts.

No. We'll need a view of descendant lines at the source parent, not at the destination head. Oh, but if you can rebase the source commit to destination cleanly, you can absorb changes from there.

No, that was specifically the issue. I don't think it's possible for a reorder to be conflict-free if there was something to absorb.

But I think it may be possible to do a workaround by first doing the new to old absorb and then using interdiff on the result to get a patch that I could use to split out the changes. But maybe it's not quite that simple, since that only splits out the changes from the new commit. It doesn't give me a way to extract the relevant lines from the older commit.