| Comment: | merge merge-probe: mergeability for a caller-named pair (#134) |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
83734fcc3d876fbbbddde846d1ab6884 |
| User & Date: | dmestas on 2026-08-24 02:26:19.135 |
| Other Links: | manifest | tags |
|
2026-08-24
| ||
| 11:15 | merge landing-title-138: first line of -m is the landing title (#138) check-in: da4fa8dcbe user: dmestas tags: trunk | |
| 11:06 |
landing open: the first line of -m is the title, the rest is the prose
The whole message went into the H card and the body both, so a multi-paragraph -m minted a multi-paragraph heading and carried the same text twice. An H card is one token (§4.7.7). The split is at the first newline, not the first blank line, so a two-line message cannot mint a two-line title either. ls and show read only a title's first line: landings minted before this are immutable, so a reader has to cope with them, not merely stop making more. A message with no title line is refused before the branch lookups and the store scan. Fixes #138 closed check-in: 3e565c1caa user: dmestas tags: landing-title-138 | |
| 10:16 |
update: carry uncommitted work across the move instead of refusing it
A dirty tree is now three-way merged (current check-in, working file, target) rather than rejected, so a branch tip that advanced under uncommitted work can be joined. Previously update, merge and stash all refused that state, leaving commit --allow-fork as the only exit -- the guard that keeps forks deliberate was manufacturing them. The fork guard itself is unchanged. applyCheckinWith scans the tree once and calls back for the merge policy; handing carries in instead would scan every clean update twice, which cost a 20k-file no-op update 63%. Paths that cannot merge either way (type change, edited here / deleted there) are named and refused before anything mutates. Fixes #135 closed check-in: 7fcc9b5ee1 user: dmestas tags: update-dirty-tree-135 | |
| 02:26 | merge merge-probe: mergeability for a caller-named pair (#134) check-in: 83734fcc3d user: dmestas tags: trunk | |
| 02:17 |
merge --probe: mergeability for a pair the caller names (#134)
landing show answers the same question but must find the record first, which is a full-store walk. A consumer with its own index already knows the record and both tips; --probe lets it ask about the pair and pay only for the merge. Release build on a 20MB store: 0.01s against 0.90s. Writes nothing, never autosyncs, and exits 0 whatever the answer -- 'has conflicts' is an answer, not a failure, so a caller reads the line rather than the status. Being a read it takes -R, and then --into is required because there is no checkout to supply the other side. The probe moves out of landing and next to the merge engine: one implementation, three callers. A real merge now refuses -R by name instead of failing as a discovery miss that tells you to pass the flag you just passed. closed check-in: aff1d04310 user: dmestas tags: merge-probe | |
| 01:35 | merge diff-ignore-ws: zit diff -w ignores whitespace-only changes (#130) check-in: f863b8d6ef user: dmestas tags: trunk | |