ada-git-history-preserving-moves

Preserves git history across file renames using git mv and --follow verification.

Updated Jul 23, 2026
One-click install
npx skills add https://github.com/wubing7755/Ada --skill ada-git-history-preserving-moves-wubing7755
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ada-git-history-preserving-moves
Source: https://github.com/wubing7755/Ada/tree/main/skills/software-development/ada-git-history-preserving-moves
Command: npx skills add https://github.com/wubing7755/Ada --skill ada-git-history-preserving-moves-wubing7755

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Renaming or moving files in git often silently breaks history traceability: git log --follow stops at the rename, especially when a same-path replacement file is added in the same commit. This Skill provides the exact commands and verification steps to keep pre-move history intact. ## Core Features & Use Cases - Rename Verification Protocol: Uses git mv plus git diff --cached --name-status HEAD to confirm the staged diff records an R### rename before committing, and git log --follow after. - Same-Path Replacement Fix: Explains why moving README.md to README.zh-CN.md while adding a new English README.md in one commit destroys rename detection, and prescribes a two-commit split. - Broken-Staging Recovery: Provides a step-by-step recipe (backup, git reset, restore HEAD version, clean git mv, restore edits) to rebuild a rename when the index was staged incorrectly. - Use Case: During a README bilingual cutover or documentation tree restructure, follow the checklist to guarantee every moved file retains its full --follow history. ## Quick Start Ask the agent to rename README.md to README.zh-CN.md while keeping git log --follow history intact.

Frequently Asked Questions about ada-git-history-preserving-moves

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I rename a file in git without losing history?▼

Use git mv to stage the rename, then verify with git diff --cached --name-status HEAD that the diff shows an R### rename entry before committing. After committing, confirm git log --oneline --follow -- new-path shows the pre-move commits.

Why does git log --follow stop at my file rename?▼

History breaks when the rename was committed together with a new file at the old path. Git pairs the old and new same-path files as a modification, consuming the rename source, so the moved file is recorded as a plain addition instead of a rename.

Can I rename README.md and add a new README.md in one commit?▼

No, a single commit cannot record the rename when a same-path replacement exists. Split it into two commits: first a pure git mv rename verified as R###, then a second commit adding the new same-path file and dependent validator changes.

How do I fix a staged rename that git did not detect?▼

Back up the new and edited files, run git reset to unstage, restore the HEAD version of the old path, remove the target path, then run git mv on a clean target and restore your edits. Commit the rename and the replacement separately.

Does git mv guarantee rename detection in the diff?▼

No, git mv only stages the move; rename detection happens at diff time based on content similarity. You must verify the staged diff shows R### before committing, because same-path modifications can prevent the rename from being recorded.