alt Hacker News> `absorb` assigns the changes based on whichever previous commit most recently touched those files, which sometimes doesn't actually correspond to which commit should own these particular changes.
I’m pretty sure `jj absorb` (and its predecessors, `git-absorb` [0] and `hg absorb`) are smarter than this, instead looking at the actual diffs.
Replies
oefrha • today at 2:49 AM
Yeah it’s smarter than that, but as a daily user of git absorb it still gets things wrong fairly often though—like a couple times a week often for me. Plus the changes it can’t absorb automatically (e.g. a lone doc change it can’t find peers for).
jolux • yesterday at 10:04 PM
Also `sl absorb`.
Ah yeah, you're right, that's a misrepresentation on my part - it's based on lines, not the file:
> [absorb] splits changes in the source revision and moves each change to the closest mutable ancestor where the corresponding lines were modified last. If the destination revision cannot be determined unambiguously, the change will be left in the source revision.
I use absorb fairly often, fwiw. It's great for when I want to make a patch to a commit that will easily absorb into its right place. And I also, sometimes, prefer the more intentional approach where I decide exactly where each hunk will go.