- Added testUserAlice constant for 'alice' in test files
- Added windowsOS constant for 'windows' in test files
- Added testIssueBD1/testIssueBD2 constants for 'bd-1'/'bd-2' in test files
- Added testVersion100 constant for '1.0.0' in version tests
- Added testIssueCustom1 constant for 'custom-1' in lazy init tests
Closes bd-54
Amp-Thread-ID: https://ampcode.com/threads/T-0a4e5d44-2d95-4948-8f4a-d8facf8657c7
Co-authored-by: Amp <amp@ampcode.com>
Bug: updateDependencyReferences() was incorrectly updating ALL dependencies
in the database during collision resolution with --resolve-collisions,
including dependencies belonging to existing issues.
Root cause: The function checked if dep.IssueID was in idMapping keys
(old imported IDs like 'bd-1'), but those are also the IDs of existing
database issues. This caused existing dependencies to be incorrectly
modified or deleted.
Fix: Changed logic to only update dependencies where IssueID is in
idMapping VALUES (new remapped IDs like 'bd-295'). This ensures only
dependencies from remapped issues are updated, not existing ones.
During normal import flow, this is effectively a no-op since imported
dependencies haven't been added to the database yet when RemapCollisions
runs (they're added later in Phase 5 of import_shared.go).
Changes:
- Updated updateDependencyReferences() in collision.go to build a set
of new remapped IDs and only update dependencies with those IDs
- Added comprehensive documentation explaining the correct semantics
- Added regression tests: TestRemapCollisionsRemapsImportedNotExisting
and TestRemapCollisionsDoesNotUpdateNonexistentDependencies
- Skipped 3 tests that expected the old buggy behavior with clear
notes about why they need to be rewritten
Real-world impact: In one case, 125 dependencies were incorrectly
deleted from 157 existing issues during collision resolution.
Fixes https://github.com/steveyegge/beads/issues/120
Fixes bd-56
