| Comment: | Merge branch 'fix/update-renames' into feat/submanifest-reader
# Conflicts: # CHANGELOG.md |
|---|---|
| Timelines: | family | ancestors | descendants | both | main | trunk | feat/submanifest-reader |
| Files: | files | file ages | folders |
| SHA3-256: |
5d0a52d7068541f34c9e5e1e125fabb0 |
| User & Date: | [email protected] on 2026-10-19 15:59:12.000 |
| Other Links: | branch diff | manifest | tags |
|
2026-10-19
| ||
| 16:25 | Merge branch 'fix/update-undo' into feat/submanifest-reader check-in: da7c8a19cd user: [email protected] tags: feat/submanifest-reader, main, trunk | |
| 16:10 |
fix(checkout): save undo state in Update, as fossil does
Update saved no undo state, so nothing could reverse it. It now reads the file of every step that writes or removes one before writing, as fossil's update calls undo_save, and saves those files with copies of vfile and vmerge and the checked-out version in the same transaction that moves the checkout to the target. If a write fails partway the files are put back, as fossil's undo_rollback does. Checkout.Undo and Checkout.Redo (internal and public) swap that state back and forth and keep checkout-hash naming the restored version. The undo package gains ReadFile, SaveTx and RestoreFiles, and its undo table now has fossil's schema (isExe, unique pathname, rowid order, the executable bit read from disk), so fossil undo reverses a go-libfossil update and Checkout.Undo reverses fossil update; fossil 2.28 interop tests check both. Under js/wasm, which has no undo package, Update saves nothing. Tracked in #446 check-in: 294a537880 user: [email protected] tags: feat/submanifest-reader, main, trunk | |
| 15:59 |
Merge branch 'fix/update-renames' into feat/submanifest-reader
# Conflicts: # CHANGELOG.md check-in: 5d0a52d706 user: [email protected] tags: feat/submanifest-reader, main, trunk | |
| 15:55 |
fix(checkout): follow renames between versions in Update, as fossil does
Update matched files by name, so a local edit to a file the target renamed was left behind as an untracked file under the old name while the new name got the target's content. path.NameChanges ports fossil's find_filename_changes with revOK: the renames along the primary path from the checkout's version up to the common ancestor and down to the target, a rename on the way up taken backwards. Update uses it as update.c does: a changed file the target renamed is matched to the target's file under its new name. A merge is written under the new name and the old name removed; when the target only renamed the file, nothing is written and the edit stays under the old name, untracked, as in fossil, which Unmerged now reports. A local rename is not followed, as in fossil. fossil 2.28 interop tests compare both directions: a target-side rename and edit, a target-side pure rename, a local rename of a file the target edited, and a rename on the checkout's own branch followed backwards to a sibling. Tracked in #445 check-in: c88a801cf9 user: [email protected] tags: feat/submanifest-reader, main, trunk | |
| 14:40 |
docs: state where text Julian times are checked and how sweep errors read
Only macOS arm64 and linux-x64 fossil have been compared bit for bit, so the rebuild test no longer claims Windows is exact. julian.go says which long doubles fall back to 53 bits wrongly, and ExpandAll's doc says its errors match Cache.Expand's in kind, not always in wording. check-in: e4c84f20f9 user: [email protected] tags: feat/submanifest-reader, main, trunk | |