It's not completely true, you can easily lose data in Git by accident. Here's an example. Suppose we have a single "master" branch, pointing to commit A. You create a new "feature" branch, making commits B, and then C. You realize that B and C are actually unrelated, so you want each of them to have separate branches. You git rebase --interactive onto master, picking only commit C. This way feature branch has commit C with parent A. Now, you git checkout commit B, which should put you into detached HEAD state, from which you plan to create a second feature branch. Alas, something has triggered git gc in the meantime, and commit B has been garbage collected, as it was no longer pointed to by anything.

Something like this happened to me, breaking the whole Chromium repo for half an hour. Definitely not fun.

> You git rebase --interactive onto master, picking only commit C.

So during an interactive rebase you drop one commit, and pick the other, then are upset at git for dropping your commit? It did exactly what you asked of it.

This would have easily been avoided if you had branched off your feature branch into a new one and did the interactive rebase there. Your old feature branch is still present, which you could rebase interactively, or drop HEAD so you only have the other commit, or whatever other thing to meet its needs.

Sure, I know now exactly what happened, and what I should have done in order to avoid it. My point here is that "Git repo is immutable and cannot lose data" is a lie, and people who believe it (like I did at the time -- hey, if anything breaks on rebase, I can always git reflog and reset to good state, right?) will have a bad time at some point down the line, so it's better to stop this lie from spreading.

That's odd. gc shouldn't be collecting anything less than 2 weeks old by default.

That's not exactly what happened, but the idea is the same. You can add a 2 week vacation in the meantime if it helps you imagine it.

I would recommend taking advantage of git's incredibly cheap branches and drop a lifesaving breadcrumb on all the commits I was planning to keep. One of the first steps I tell people when showing the rebase workflow is leaving behind a 'safe' marker, and how to reset back to it if the rebase gets too hairy.