Chapter 1.8☕ 10 min read

git show & git mv

File ka naam OS se badloge toh history toot jaayegi. git mv use karo — history safe rahegi.

01git show — Your Time Viewer

git show is your time viewer. It displays the full details of a specific commit: the metadata (who, when, why) and the diff (what changed).

Without arguments, git show shows the latest commit (HEAD). It is equivalent to git show HEAD.

You can point it at any commit:

git show <hash> — show a specific commit by its hash (full or abbreviated)
git show HEAD~3 — show the commit 3 parents back from HEAD
git show <branch> — show the latest commit on a branch

Output includes: commit hash, author, date, commit message, and the full diff of changes.

git show --stat — show only the summary (which files changed, how many insertions/deletions) without the full diff.

git show --name-only — just the filenames that changed, no diff counts.

# Show the latest commit
git show
# commit a94a8fe5ccb19ba61c4c0873d391e987982fbbd3 (HEAD -> main)
# Author: Sai Kumar <sai@devinhyderabad.com>
# Date:   Mon Jan 6 10:00:00 2025 +0530
#
#     feat: add login page
#
# diff --git a/app.js b/app.js
# new file mode 100644
# index 0000000..e69de29
# --- /dev/null
# +++ b/app.js
# @@ -0,0 +1,5 @@
# +function login() {
# +  authenticate(user);
# +}

# Show specific commit
git show abc1234
git show HEAD~2       # 2 commits ago

# Show just the summary (no diff)
git show --stat
#  app.js | 5 +++++
#  1 file changed, 5 insertions(+)

# Show just filenames
git show --name-only
# app.js

git show is completely safe — it is a READ-ONLY command. It never modifies your working directory, staging area, or repository. You can run it on any commit, any branch, any file without fear. Think of it as opening a book to any page — you can read, but you cannot change anything.

02Viewing File at a Specific Commit

git show <commit>:<filepath> — view the content of a file AS IT WAS at that specific commit.

This is like opening a file from the past. The file content is displayed on your terminal. You are just looking, nothing is modified.

Key patterns:

git show HEAD~3:app.js — what did app.js look like 3 commits ago?
git show abc1234:src/config.js — what was in config.js at commit abc1234?
git show main:package.json — what is in package.json on the main branch right now?

This does not modify anything — it is a READ-ONLY operation. You are just viewing.

To RESTORE an old version: use git restore -s <commit> <file> (covered in Chapter 1.7).

# View file as it was 3 commits ago
git show HEAD~3:app.js
# function oldVersion() {
#   return "this was 3 commits ago";
# }

# View file from a specific commit
git show abc1234:config.json
# { "version": "1.0.0" }

# Compare current vs old version
git show HEAD:app.js     # current version
git show HEAD~5:app.js   # version 5 commits ago

# View file on another branch
git show main:package.json
git show feature:src/app.js

# List files in a commit directory
git show HEAD~2:src/
# tree HEAD~2:src/
# app.js
# config.js
# utils/

# Save old version to a file (without restoring)
git show HEAD~3:app.js > app_old_version.js

03git mv — Rename Without Breaking History

git mv old_name new_name renames or moves a file through Git.

Without git mv: if you rename a file in your OS, Git sees it as DELETE old + ADD new untracked. History breaks!

With git mv: Git records the rename properly, so git log --follow can trace the file's history across renames.

git mv is actually shorthand for: mv old new + git add new + git rm old. Same result, fewer steps.

After git mv, you must commit the rename. The rename is staged automatically.

You CAN rename without git mv (using OS rename + git add), but Git may not detect the rename relationship, especially if content also changed.

# WRONG: rename in OS without telling Git
mv app.js application.js
git status
# deleted:    app.js        (Git thinks you deleted it!)
# Untracked: application.js (Git thinks it is a new file!)
# History of app.js is BROKEN for application.js

# CORRECT: use git mv
git mv app.js application.js
git status
# renamed:    app.js -> application.js  (Git understands!)

# Commit the rename
git commit -m "refactor: rename app.js to application.js"

# View history including before the rename
git log --follow application.js
# Shows commits from when the file was still called app.js!
# Without --follow, history starts at the rename commit

# Move file to a different directory
git mv app.js src/app.js
git commit -m "refactor: move app.js to src directory"
git log --follow src/app.js

💡 Pro Tip: Always use git log --follow <filename> when viewing the history of a renamed file. Without --follow, git log only shows history after the rename. With --follow, Git traces the rename and shows the full history including when the file had its old name.

04How Git Tracks Content, Not Names

Git does not track files by name — it tracks content by SHA-1 hash.

When you rename a file in your OS, Git sees: (1) the old filename is gone (deletion), (2) a new filename appears with the same content (addition).

Git MAY detect the rename if content is identical (rename detection), but it is not guaranteed, especially if you also changed the file content.

git mv explicitly records the rename, making history tracking reliable.

The worst case: rename AND edit in the same commit. Git almost never detects this as a rename without git mv.

Case-sensitivity issue on Windows/macOS: git mv file.txt File.txt may fail because the OS sees them as the same file.

# The problem: rename + edit = broken history
# WITHOUT git mv:
mv app.js application.js         # OS rename
echo "// updated" >> application.js  # also edit the file
git add app.js application.js    # stage both
git status
# deleted:    app.js
# new file:   application.js
# Git does NOT detect this as a rename!
# The --follow flag will not work properly.

# WITH git mv:
git mv app.js application.js     # Git-tracked rename
echo "// updated" >> application.js  # edit after rename
git add application.js           # stage the edit
git status
# renamed:    app.js -> application.js
# modified:   application.js (the edit)
# Git correctly detects rename + modification!

# Case-sensitivity trap (Windows/macOS)
git mv config.js Config.js
# fatal: destination exists
# Fix: use a temporary name
git mv config.js config_temp.js
git mv config_temp.js Config.js

05Power Tricks — Merge Conflict Stages & More

git show has powerful tricks beyond basic commit inspection:

git show HEAD:path/to/file — view any file at any commit. Read-only time travel.
git show --format="%H %s" <hash> — custom format showing only hash and subject.
git show <tag> — view the tagged commit (useful for release notes).
git show HEAD~1:./relative/path.js — use relative paths from current directory.
git show :0:app.js — show the file as it exists in the staging area (index).
git show :2:app.js and :3:app.js — show ours/theirs versions during a merge conflict.

These power tricks turn git show into a Swiss Army knife for inspecting Git history.

# View staged version of a file
git show :0:app.js
# Shows what is currently in the staging area

# During merge conflict — see both versions
git show :2:app.js   # "ours" (your branch)
git show :3:app.js   # "theirs" (incoming branch)

# View a specific release
git show v2.1.0
# Shows the commit that v2.1.0 tag points to

# Custom format output
git show --format="%H%n%an%n%s" --no-patch HEAD
# Full hash, author name, subject line
# --no-patch = do not show the diff

# Compare file across commits
diff <(git show HEAD~3:app.js) <(git show HEAD:app.js)
# Shows what changed in app.js over last 3 commits

# Find which commits touched a file, then inspect
git log --oneline -- app.js | head -5
git show abc1234 --stat    # summary of that commit
git show abc1234:app.js    # file content at that commit

Merge conflict stages :2 and :3 are Git's secret weapon during conflicts. :2:file shows your version (what you had before the merge), :3:file shows their version (what they changed). You can open both side-by-side, compare them, and build the correct resolution. No more guessing what changed — you see both versions clearly.

Lo kar liya — Key Points:

✅ git show displays a commit's metadata and diff — without arguments, it shows the latest commit (HEAD)
✅ git show <commit>:<filepath> views a file AS IT WAS at that commit — read-only time travel
✅ git show --stat shows a summary of which files changed without the full diff
✅ git mv old new renames/moves a file through Git, preserving history linkage
✅ OS rename without git mv causes Git to see DELETE + ADD instead of RENAME, breaking git log history
✅ git log --follow <filename> traces file history across renames — essential after git mv
✅ git show :0:<file> shows staged version, :2:<file> shows ours and :3:<file> shows theirs during conflicts

Previous1.7 — git restore & git switch 📋 All Chapters Next Chapter2.1 — git reflog — Time Machine →