Ivo's label fix vanished from the release clone

Lab machine

A private Linux machine with the problem already set up. Sessions last up to 60 minutes.

Dmitri Vos opened REL-262 at 16:50SEV-4

Dmitri tidied his clone of Waybill before going home, and Ivo's South Sorting label fix went with it. South Sorting opens tomorrow at 06:00, tonight's build needs the fix, and Ivo is on a plane until Thursday.

Nothing was pushed, so the only copy of Ivo's commit is in Dmitri's repository. A reset or a deleted branch removes a name, not the commit: Git keeps a log of every place HEAD has been.

"Please don't make me ask Ivo to redo it. Also, my runbook edit isn't committed yet, don't lose it." (Dmitri)

The hard part is the recovery. Since the loss, main has moved on by one commit, and there is uncommitted work in the tree.

Your task

Put Ivo's South Sorting fix back on main as his own commit. Keep Dmitri's newer changelog commit, leave out anything else that was dropped, and do not touch the runbook edit.

On the machine

notes/dmitri-terminal.txt: what Dmitri typed
git reflog: everywhere HEAD has been, including commits no branch points to
git log --oneline main, git status
git show <commit>: what a lost commit contains

Timeline

10:12Ivo commits the South Sorting (depot-9) label template and printer, then leaves for the airport.

15:40Dmitri tidies his clone before going home.

16:20He commits the 2.5.3 changelog and starts a runbook edit.

16:50"Where did Ivo's label fix go?"

Done when

main has Ivo's South Sorting fix, recovered as his commit, not retyped.
Dmitri's later changelog commit stays on main, and nothing else that was dropped comes back.
The unfinished runbook edit is still in the working tree, uncommitted.

How it is checked:The checker requires main to be checked out, to still contain Dmitri's 2.5.3 changelog commit, and not to contain the WIP debug code. It then requires depot-9 in release/depot-labels.csv and Ivo's South Sorting template on main, from a commit whose author is Ivo Petrov, and the runbook edit still uncommitted in the working tree.

Passed. Here is how others fixed it

This lab has 2 versions. Reset for a fresh machine, and you may get a different one.

Break it for a friend. Pick the version they get, and the link is copied for you to send: version 1 · version 2

Other fixes that also pass:

`git branch south-sorting <hash>`, then `git merge south-sorting` on main. It keeps Ivo's commit as it was and adds a merge commit.
`git stash`, cherry-pick, `git stash pop`. It works too, but the stash was not needed because the files do not overlap.

Fixes that look right but are not:

`git reset --hard HEAD@{n}` back to the fix. It loses Dmitri's newer commit and his uncommitted runbook edit.
Recovering the commit that was on top of the fix, which brings the WIP debug code back to main.
Retyping the change by hand. It works, but the history now says Dmitri wrote Ivo's fix.

Why it broke. Neither `reset --hard` nor `branch -D` deletes commits. They only move or remove the names that point to them, and the reflog keeps every position HEAD has had for about 90 days. The trap is the recovery itself. Moving main back to the old commit drops Dmitri's newer commit, `--hard` destroys the runbook edit, and recovering the commit below the fix brings back the WIP code he meant to drop. Copying exactly one commit onto today's main avoids all three.

How Mara worked it

cat notes/dmitri-terminal.txt, then git status and git log --oneline -5
Learn what was run and what must not be lost (the runbook edit, the newer commit) before typing anything.
git reflog | head -20
The reflog is the list of places HEAD has been. The lost commit is one of them.
git show <hash> --stat
Confirm it is Ivo's fix and only Ivo's fix. The commit next to it is Dmitri's WIP.
git cherry-pick <hash> on main
One commit onto today's main, author kept, working tree untouched.
git log --format='%h %an %s' -3 and git status
The fix is Ivo's, the changelog is still there, and the runbook edit is still uncommitted.

Hints

Hint 1

Dmitri's terminal says what he ran, not what it did. `git reflog` shows every place HEAD has been.

Hint 2

Find the entry where Ivo's commit was made, and `git show` it before you use it.

Hint 3

main has moved on since. Moving main back would lose Dmitri's changelog commit and, with --hard, the runbook edit.

Hint 4

`git cherry-pick <commit>` copies one commit onto the current branch and keeps its author. It works with an uncommitted change in an unrelated file.

Show the solution

Run `git reflog` and find the commit "labels: South Sorting (depot-9) template and printer". Check it with `git show <hash>`. On main, run `git cherry-pick <hash>`. The runbook edit is in another file, so it stays as it was. Confirm with `git log --format='%h %an %s' -3` and `git status`.

Version Control with Git

Undoing and recovering

Revert, reset, and restore each undo something different. The reflog means almost nothing committed is truly lost.

Four kinds of "undo"

"Undo it in Git" can mean four different operations. Choose by asking what must change and who already has the commits.

Goal	Tool	Rewrites history?
Discard edits to a file on disk	`git restore <file>`	No (but loses the edits)
Unstage a file	`git restore --staged <file>`	No
Undo a commit others already have	`git revert <commit>`	No. It adds an inverse commit
Move my branch to a different commit	`git reset <commit>` with `--soft`, `--mixed`, or `--hard`	Yes, for this branch

For anything already pushed to a shared branch, revert is the default answer. It records "we undid X, and why" as a normal commit, and it composes with the good commits that came after.

Reset, demystified

git reset <commit> always moves the current branch to <commit>. The flag decides how much else follows:

--soft: only the branch moves. The index and working tree are untouched, so the undone commit's changes appear staged. This is useful for squashing the last few local commits.
--mixed (default): the branch moves and the index is reset to match. Changes now appear as unstaged edits.
--hard: branch, index, and working tree are reset. Uncommitted work is overwritten.

Only --hard destroys anything, and only uncommitted work. Committed work is still in the object database.

The reflog: Git's flight recorder

Every time HEAD or a branch moves (commit, reset, checkout, rebase, merge), Git appends an entry to the reflog:

git reflog            # where HEAD has been
git reflog show main  # where main has been

A commit that "disappeared" after a reset is still an object, now unreachable. Find its ID in the reflog, give it a name with git branch rescue <id>, and it is safe again. Unreachable objects are only pruned by garbage collection after a grace period (two weeks for loose objects and longer for reflog entries, by default). Recovery is usually possible even after a bad afternoon. git fsck --lost-found finds dangling commits when the reflog has no entry, for example in a fresh clone.

The reflog is local. It records your repository's ref movements, not the server's. A commit that only ever existed in someone else's clone must be recovered from their reflog.

Recovering calmly

A recovery routine that never makes things worse:

Stop and protect. Stash or commit any uncommitted work to a scratch branch. It has no other copy.
Find. git reflog, git log --all --oneline, and git fsck --lost-found.
Name it. git branch rescue/<what> <id>. Now nothing can garbage-collect it.
Inspect. git show rescue/<what> to confirm it is the approved commit.
Restore with a reviewed merge, cherry-pick, or fast-forward, not a force-push to a shared branch.

When a revert is not one command

git revert <commit> applies the inverse of one commit on top of today's branch. Two things make it harder than that:

A later commit touched the same lines. Git stops with a conflict, because the inverse no longer applies cleanly. Resolve it to today's file with only the bad change undone. Taking either side wholesale silently undoes the later work or keeps the bug. Finish with git add and git revert --continue.
The change came in through a merge. git revert -m 1 <merge> undoes everything the merged branch brought, which is rarely what you want when one commit inside it was bad. Revert that commit instead. Reverting a merge also has a lasting effect: Git considers the branch's commits already merged, so re-merging the branch later brings nothing back until you revert the revert.

Either way, run the check that failed before you push. A protected branch accepts the fix as a fast-forward and nothing else.

Rewriting history, with care

Interactive rebase and git filter-repo can rewrite many commits: squash, reorder, or strip a file from all history. They are the right tool for unpublished work and for real emergencies such as removing a leaked secret or a huge binary. On shared branches they need coordination, because every collaborator must re-clone or reset. The “Releases, tags, and shared history” notes cover how to do that and what to do first.

Key terms

Revert: A new commit that applies the inverse of an earlier commit. History is preserved and safe on shared branches.
Reset: Moves the current branch pointer (and optionally the index and working tree) to another commit.
Reflog: A local log of where HEAD and each branch pointed over time. It is the safety net for "lost" commits.
Unreachable object: A commit no ref points to. It survives until garbage collection, which by default waits weeks.

Read further

Pro Git, 2nd edition, 2.4 "Undoing Things" (Free to read online (CC BY-NC-SA 3.0))
commit --amend, unstaging, and unmodifying files, and the warnings about which of these lose work.
Pro Git, 2nd edition, 7.7 "Reset Demystified" (Free to read online (CC BY-NC-SA 3.0))
The three trees again, and the step-by-step diagrams of what reset --soft, --mixed, and --hard move. This section makes reset predictable.
Pro Git, 2nd edition, 10.7 "Maintenance and Data Recovery" (Free to read online (CC BY-NC-SA 3.0))
Recovering a lost commit with git reflog and git fsck --lost-found, and when Git's garbage collection actually removes unreachable objects.
Pro Git, 2nd edition, 7.6 "Rewriting History" (Free to read online (CC BY-NC-SA 3.0))
Interactive rebase and filter-branch (and the note pointing to git filter-repo). Read it to know the tools exist and why they are dangerous on shared branches.

Ivo's label fix vanished from the release clone REL-262