Hacker News Reader

Comment by rafekett | Hacker News Reader

I was a little disappointed to not see anything I don't use regularly. Some explanation of reflog might be helpful, in addition to a bit of detail on git internals that explains why things in Git are never really deleted until you run `git gc`. For instance, just yesterday I realized that a branch I had deleted erroneously (bad branch name) contained a few days of work. I looked in git reflog to find the SHA for the last time I checked it out, checked out that SHA, then made a new branch. No work lost. If I didn't know that, I'd be out a few days of effort.

View on HN

> things in Git are never really deleted until you run `git gc`.

wording there is a bit dangerous, see this snippet from `man git-gc`:

    Some git commands run git gc --auto after performing operations that could create many loose objects.

It doesn't say what those commands are. I've always found what I'm looking for in the reflog, so either I've been lucky or this cautionary note in the man page is conservative.

git-gc defaults to preserving any objects less than 14 days old. This is configurable.

`git gc` will not remove objects mentioned in the reflog. The reflog entry for a commit that is not referenced from any refs (e.g., because you deleted the branch it was on) will last for `gc.reflogExpireUnreachable` time units. By default this is 30 days.

After that, then the object is subject to pruning by `git gc`, and may go immediately, or up to 14 days later, depending on the packing. That 14-day grace period is there for objects that never got referenced in the first place (so a tree that you are building to make a commit, for example, would not go away before you run `git commit`).

Great suggestions, thanks :)

Reply on news.ycombinator.com