GIT-MV(1)

💅 GIT-MV(1) — the git manual, but make it cute 🎀

okay so real talk: this is git-mv, straight out of the Git Manual. she moves stuff. she renames stuff. she's lowkey the friend who helps you pack. let's get into it bestie ✨

---

🌸 NAME 🌸

git-mv — move or rename a file, a directory, or a symlink

---

🦋 SYNOPSIS 🦋

git mv [-v] [-f] [-n] [-k] <source> <destination>
git mv [-v] [-f] [-n] [-k] <source>... <destination-directory>

---

✨ DESCRIPTION ✨

Move or rename a file, directory, or symlink. that's it. that's the whole vibe 💅

So there's two forms, right, and they're giving very different energy:

• Form one — you take source and rename it to destination. but bestie, source must exist, and it has to be a file, a symlink, or a directory. no imaginary friends. no cap.
• Form two — destination-directory has to be a directory that actually already exists, and all the sources you listed get moved into it. like, they all go live in that house together 🏠

The index gets updated after it completes successfully, but — and this is the important part, don't @ me — the change must still be committed. so don't just walk away thinking you're done 😭

---

💖 OPTIONS 💖

• -f, --force — force the renaming or moving of a file even if the destination already exists. she will simply bulldoze right on through 🔥
• -k — skip move or rename actions that would lead to an error condition. an error happens when a source is neither existing nor controlled by Git, or when it would overwrite an existing file unless -f is given. so like, she just quietly skips the drama 🧚
• -n, --dry-run — do nothing; only show what would happen. purely a vibe check, zero commitment 🙈
• -v, --verbose — report the names of files as they are moved. she'll narrate her every move, main character energy 👑

---

🎀 SUBMODULES 🎀

Moving a submodule that uses a gitfile (which means they were cloned with a Git version 1.7.8 or newer) will update the gitfile and core.worktree setting so the submodule actually works in its new location. iconic, honestly.

It also will attempt to update the submodule.<name>.path setting in the gitmodules(5) file and stage that file — unless -n is used, in which case, no staging, we're just looking ✨

---

💀 BUGS 💀

okay so here's the messy part. each time a superproject update moves a populated submodule (like, for example, when switching between commits before and after the move), a stale submodule checkout will remain in the old location and an empty directory will appear in the new location. it's giving "left my stuff at my ex's place" 😭

To populate the submodule again in the new location, the user will have to run git submodule update afterwards. that's the fix, run it.

And listen — removing the old directory is only safe when it uses a gitfile, because otherwise the history of the submodule will be deleted too. so please, bestie, check before you rm -rf, that's how people lose their whole lives 💀

Both of those steps will be obsolete when recursive submodule update has been implemented. future us is gonna be so chill about this.

---

🫶 GIT 🫶

Part of the git(1) suite. one big happy family 🌈

---

okay that's the whole page, mwah 💋 this edition came from Git 2.56.0, dated 2026-09-27 — so if you're reading this from the future, hi, hope your submodules are fine 🦋⭐