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
When importing issues with explicit high IDs (e.g., bd-100), the
issue_counters table wasn't being updated. This caused the next
auto-generated issue to collide with existing IDs (bd-4 instead of bd-101).
Changes:
- Add SyncAllCounters() to scan all issues and update counters atomically
- Add SyncCounterForPrefix() for granular counter synchronization
- Call SyncAllCounters() in import command after creating issues
- Add comprehensive tests for counter sync functionality
- Update TestImportCounterSyncAfterHighID to verify fix
The fix uses a single efficient SQL query to prevent ID collisions
with subsequently auto-generated issues.
TestImportCounterSyncAfterHighID demonstrates that importing an issue
with a high explicit ID (bd-100) doesn't sync the auto-increment counter,
causing the next auto-generated ID to be bd-4 instead of bd-101.
This test currently fails and documents the expected behavior.
Fixed critical issues identified in code review:
- Fixed invalid Go version (1.25.2 → 1.21) in go.mod
- Fixed unchecked error in import.go JSON unmarshaling
- Fixed unchecked error returns in test cleanup (export_import_test.go, import_collision_test.go)
- Removed duplicate test code in dependencies_test.go via helper function
Added release infrastructure:
- Added 'bd version' command with JSON output support
- Created comprehensive CHANGELOG.md following Keep a Changelog format
- Updated README.md with clear alpha status warnings
All tests passing. Ready for public repository opening.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implements --resolve-collisions flag for import command to safely handle ID
collisions during branch merges. When enabled, colliding issues are remapped
to new IDs and all text references and dependencies are automatically updated.
Also adds comprehensive tests, branch-merge example, and documentation.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
