I don't have any plan to implement incremental UI for file annotation, but I
think the new API is nicer in that they have fewer function arguments.
Note that this wouldn't help implement interactive UI to go ancestor annotation
by clicking annotated line. To achieve that cheaply, we'll need weave-like data.
Suppose we add "jj file annotate" option to specify the search domain or depth,
the root commit within the range can be displayed as the boundary commit. "git
blame" for example displays boundary commits with ^ prefix.
This follows up 85e0a8b0687e "annotate: add option to not search all ancestors
of starting commit."
In "jj absorb", we'll need to calculate annotation from the parent tree. It's
usually identical to the tree of the parent commit, but this is not true for a
merge commit. Since I'm not sure how we'll process conflict trees in general,
this patch adds a minimal API to specify a single file content, not a
MergedTree.
The primary use case is to exclude immutable commits when calculating line
ranges to absorb. For example, "jj absorb" will build annotation of @ revision
with domain = mutable().
We might want to calculate (commit_id, range) pairs of consecutive lines in
order to "absorb" changes, for example.
This should also be cheaper since Vec<u8> doesn't have to be allocated per line.
