1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
+
-
+
+
+
+
-
+
|
An informal list of FIXMEs which don't warrant full tickets...
This is not *intended* to be a list of long-lived fixme's, but more of a scratchpad for things which come up spontaneously and shouldn't be forgotten.
In no particular order...
# Diff Engine v2
# f-vdiff
The "v2" diff engine (2021 edition), when outputing to a format which uses "chunk headers" (like unified) can sometimes split two chunks which are directly adjacent:
|
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
+
+
+
+
|
54 58 static int f_vdiff_hash(fsl_card_F const * const fc,
```
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.
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."
## Split Diff (a.k.a. side-by-side) Column Limit and Multibyte Characts
The split diff renderer can truncate multi-byte characters when a column width limitation is placed on it. It looks like it's time to finally port in some of the character-level fiddly bits for UTF8 handling.
# Crosslinking...
2021-04-12: The issue described below may have been resolved by the bug fixed in [](2791e665cca2eae2).
Running `f-parseparty -t c --crosslink` generates the expected number of mlink/plink entries but *sometimes* leaves (as it were) some commit other than the tip marked as a leaf, which causes `fossil update` to warn about having multiple leaves. We can get around this by running `fsl_repo_leaves_rebuild()` after it crosslinks everything, but that would simply hide the bug (if it *is* a bug - see below), which would presumably appear again at some point after a single checkin gets processed.
That said: it's unclear whether this is a genuine bug or a side-effect of an unfortunate parsing order. `f-parseparty` currently (as of 2021-03-11) recomputes the leaves by default if it crosslinks any checkins or tags (noting that tags can close checkins). Despite the code comments in the leaves computation, it is not "slow", taking an insignificant amount of time to run, even on the fossil and sqlite repos.
|