Note how line numbers above and below the `~~~~~` (diff chunk separator) are consecutive. fossil(1) doesn't do that because it handles the chunk separator at a higher level of the API, whereas libf moves that into the diff builder interface. That change requires that libf forego a step fossil performs which tries to merge chunks of a diff together if the distance between them is smaller than the number of context lines. That change in libf is apparently the root cause of this. It's purely cosmetic, but it's annoying. The core of the discrepancy comes from fossil mixing the output of of the diffs: most of it is done from the diff builders but some pieces, like Unified-format diff line number markers, are output from the core diff driver algorithm. That gives it more control over the output, but it also only supports a single output channel (a memory buffer), whereas libf needs to be able to support arbitrary output channels (some of which, like ncurses widgets, cannot simply be streamed-to).

TODO: figure out how to adapt libf to (A) not require that the higher-level API know such details about the diff builder but (B) still be able to apply that "cosmetic optimization."

Checkin [](08fdbacefacd2b) partially resolves this, but only for the case when we're using line numbers (as in the above example).

## The Unusually and Excessively Large Diff

> Update 2022-01-20: the cause of this has been narrowed down to a broken attempt in f-vdiff to report a rename, which cascades into all sorts of grief. Until this can be solved properly, f-vdiff will report a rename as an add/remove pair. Not ideal, but  it's the quickest fix for the time being.

Here's a case where libf's diff (via f-vdiff) produces a multi-hundred-meg diff compared to half a meg for fossil...

To reproduce, from the main fossil tree:

```
$ fossil co c800d2ca827c1fe5f