fix: re-lock the self-referencing git dep after the history rewrite #60

fabi · 2026-09-19T21:11:24Z

fabi commented

2026-09-19 21:11:24 +00:00

🔴 The history rewrite broke the build for every machine except this one.

crates/sylpheed-export depends on this repository by tag:

sylpheed-formats = { git = "https://git.mc02.dev/fabi/Sylpheed.git", tag = "formats-pin-2026-09-01" }

and Cargo.lock pinned it to commit #1cd5b8b1. The #49 rewrite replaced every commit, so 1cd5b8b1 no longer exists and the tag now dereferences to e2630413.

Why it looked fine

⚠️ ~/.cargo/git still holds the old object, so builds keep working on the machine that did the rewrite. A clean checkout — CI, or the other desktop — cannot resolve the locked rev at all. That is the worst shape a breakage can take, so this was measured from an empty CARGO_HOME rather than trusted to a local build.

docs/agents/CONSOLIDATION.md named this dependency as the hard blocker for a history rewrite. It was not re-checked before the push. This is the fix.

The source is unchanged

crates/sylpheed-formats has tree 55461e46 at both the old and the new commit — the rewrite never touched that crate, so the build result is identical. Only the SHA moved.

Verified

check	result
remote tag peels to	`e2630413` — matches the new lock ✅
`cargo fetch --locked`, empty CARGO_HOME	exit 0 ✅
`cargo check -p sylpheed-export --locked`	exit 0 ✅

Worth considering separately

A crate depending on its own repository by tag is what made a history rewrite dangerous in the first place. A path = "../sylpheed-formats" dependency would remove that class of breakage entirely — out of scope here, but the pin will keep needing this dance otherwise.

🔴 **The history rewrite broke the build for every machine except this one.** `crates/sylpheed-export` depends on **this repository** by tag: ```toml sylpheed-formats = { git = "https://git.mc02.dev/fabi/Sylpheed.git", tag = "formats-pin-2026-09-01" } ``` and `Cargo.lock` pinned it to commit `#1cd5b8b1`. The #49 rewrite replaced every commit, so **`1cd5b8b1` no longer exists** and the tag now dereferences to `e2630413`. ### Why it looked fine ⚠️ `~/.cargo/git` still holds the old object, so builds keep working on the machine that did the rewrite. **A clean checkout — CI, or the other desktop — cannot resolve the locked rev at all.** That is the worst shape a breakage can take, so this was measured from an **empty `CARGO_HOME`** rather than trusted to a local build. `docs/agents/CONSOLIDATION.md` named this dependency as *the* hard blocker for a history rewrite. It was not re-checked before the push. This is the fix. ### The source is unchanged `crates/sylpheed-formats` has tree `55461e46` at **both** the old and the new commit — the rewrite never touched that crate, so the build result is identical. Only the SHA moved. ### Verified | check | result | |---|---| | remote tag peels to | `e2630413` — matches the new lock ✅ | | `cargo fetch --locked`, **empty CARGO_HOME** | exit 0 ✅ | | `cargo check -p sylpheed-export --locked` | exit 0 ✅ | ### Worth considering separately A crate depending on its own repository by tag is what made a history rewrite dangerous in the first place. A `path = "../sylpheed-formats"` dependency would remove that class of breakage entirely — out of scope here, but the pin will keep needing this dance otherwise.

fabi added 1 commit 2026-09-19 21:11:24 +00:00

fix: re-lock the self-referencing git dep after the history rewrite

CI / Native — linux (pull_request) Failing after 2h42m36s

Details

CI / WASM — Web (pull_request) Successful in 33m28s

Details

CI / Formatting (pull_request) Successful in 2m29s

Details

4156cb6bd1

`crates/sylpheed-export` depends on THIS repository by tag:

    sylpheed-formats = { git = "…/Sylpheed.git", tag = "formats-pin-2026-09-01" }

and `Cargo.lock` pinned it to commit `#1cd5b8b1`. The issue-#49 history rewrite
replaced every commit, so `1cd5b8b1` no longer exists on the remote and the tag
now dereferences to `e2630413`.

⚠️ The failure is invisible here: `~/.cargo/git` still has the old object, so
builds on the machine that did the rewrite keep working. A clean checkout --
CI, or the other desktop -- cannot resolve the locked rev at all. That is the
worst shape for a breakage, which is why this was measured from an empty
CARGO_HOME rather than trusted to a local build.

`CONSOLIDATION.md` called this dependency out as the hard blocker for the
rewrite. It was not re-checked before the push; this is the fix.

The dependency's SOURCE is unchanged -- `crates/sylpheed-formats` has tree
`55461e46` at both the old and the new commit, so the rewrite never touched it
and the build result is identical.

Verified:
  * remote tag peels to e2630413, matching the new lock
  * `cargo fetch --locked` from an EMPTY CARGO_HOME -> exit 0
  * `cargo check -p sylpheed-export --locked` -> exit 0

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fabi merged commit c0a5840ce8 into main

2026-09-20 11:01:58 +00:00

fabi referenced this issue from a commit

2026-09-20 11:01:59 +00:00

Merge pull request 'fix: re-lock the self-referencing git dep after the history rewrite' (#60) from fix/relock-after-history-rewrite into main

fabi referenced this issue from a commit

2026-09-20 12:05:55 +00:00

fix(export): take the sylpheed-formats dependency by path, not by tag

fabi referenced this pull request

2026-09-20 12:06:09 +00:00

fix(export): take the sylpheed-formats dependency by path, not by tag #62

fabi referenced this pull request