perf: optimize rebase overhead 1614ms → 883ms (1.8x faster)

[svarlamov]

Summary

Optimizes the rebase authorship rewrite with two major changes:

1. Hunk-based attribution reconstruction — replaces expensive content-based matching (cat-file per commit) with replay of diff-tree hunks to shift line attributions forward through commit history
2. Combined diff-tree subprocess — merges the two separate git diff-tree calls (new commits + original commits) into a single --stdin invocation, eliminating ~500ms of process startup overhead

Key optimizations

• Hunk-based attribution reconstruction (attribution_reconstruction: 906ms → 6ms, 150x):
  Instead of reading file contents at every original commit via cat-file and doing content-based matching, replay diff-tree hunks forward to shift accumulated attributions. Each commit's note only covers lines changed in that commit, so we overlay note ranges onto the running attribution state.

• Combined diff-tree call (diff_tree: 594ms + 587ms → single call):
  Both new-commit and original-commit diff-tree calls use identical flags (--stdin --raw -p -U0). Concatenate both commit lists into one stdin pipe, partition results afterward.

• Per-commit metrics recomputation: Fixed bug where prompt_line_metrics were frozen before the commit loop, causing all rebased commits to share identical accepted_lines/overridden_lines values. Now recomputed per commit.

• Delete-then-recreate bug fixes: Clear seen_files, files_with_synced_state, current_file_contents, and current_attributions when a file is deleted, preventing stale data from corrupting attributions on re-creation.

Benchmark results (realistic monorepo benchmark — 2000 files, 8 AI-tracked, 30 feature onto 500 main)

Metric	Standard git rebase	Graphite-style (commit-tree + update-ref)
Total wall clock	0.933s	1.445s
git-ai internal	165ms	235ms
Per feature commit	31.1ms	48.1ms
Notes rewritten	531→561 (30 new)	531→561 (30 new)

Phase timing comparison

Phase	Standard	Graphite	Delta
load_rebase_note_cache	10ms	68ms	+58ms (history walk)
diff_tree_combined	34ms	24ms	-10ms
attribution_reconstruction	4ms	4ms	—
commit_processing_loop	51ms	51ms	—
notes_add_batch	51ms	77ms	+26ms
TOTAL	165ms	235ms	+70ms (+42%)

The Graphite path's overhead is entirely in load_rebase_note_cache (history walking to reconstruct commit mappings — standard rebase gets these for free from git's rewritten-list file). The core processing loop is identical.

Test results

• 3064+ integration tests: all pass
• New test_graphite_style_multi_commit_single_update_ref — verifies N notes remapped from single update-ref
• New test_rebase_file_delete_recreate_after_hunk_modification — exercises create→hunk-modify→delete→recreate sequence
• Graphite-style benchmark matching actual gt sync behavior (commit-tree replay + atomic update-ref)

🤖 Generated with Claude Code

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 11 additional findings in Devin Review.

[devin-ai-integration]

🔴 Stale current_file_contents after hunk-based transfer causes mismatched attribution on delete-then-recreate

When the hunk-based fast path is used, current_attributions is updated (line numbers shifted) but current_file_contents is NOT updated (src/authorship/rebase_authorship.rs:1452 only updates for the non-hunk path). If a file is subsequently deleted and recreated, files_with_synced_state is cleared (src/authorship/rebase_authorship.rs:1391), forcing the slow content-diff path on recreation. The slow path at src/authorship/rebase_authorship.rs:1429-1435 passes current_file_contents.get(file_path) (stale content from before hunk transfers) together with current_attributions.get(file_path) (line numbers adjusted by hunk transfers) into compute_line_attrs_for_changed_file → diff_based_line_attribution_transfer. This function builds old_line_author by indexing into the stale content using the shifted line numbers, producing corrupted attribution mappings.

Trigger sequence (4+ commits in a rebase)

1. File A first appears in commit N → content-diff (slow path) → current_file_contents["A"] = v1, current_attributions["A"] = attrs for v1
2. File A modified in commit N+1 → hunk-based transfer → current_attributions["A"] adjusted to v2 line numbers, but current_file_contents["A"] still = v1
3. File A deleted in commit N+2 → files_with_synced_state.remove("A"), but attrs and contents kept
4. File A recreated in commit N+3 → slow path uses stale v1 content with v2-shifted attrs → incorrect diff produces wrong attribution

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[svarlamov]

Fixed in commit b2a5d4c. The deletion handler now clears both current_file_contents and current_attributions for the deleted file, ensuring recreation uses a clean content-diff instead of stale data. Added regression test test_rebase_file_delete_recreate_after_hunk_modification that exercises the exact 4-commit trigger sequence (create → hunk-modify → delete → recreate).