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.