I'm doing some work with git gc and I noticed some behavior I don't understand and cannot reconcile in the docs. This pertains to checking for dangling commits with the git fsck utility.
Consider the following simple steps:
- Create a new feature branch, and make one commit.
- Switch back to master, and delete feature without merging.
- Check the reflog, as expected your commit is there.
Now, when I run git fsck, I (correctly?) don't see a dangling commit. According to this highly voted answer:
Note that commits referred to from your reflog are considered reachable.
And
And because a commit is only called dangling when it has nothing pointing to it – including reflog entries –, “reflogs for dangling commits” are not a thing.
Based on this explanation, it would be expected that Git doesn't consider the commits in my example as dangling, because they are still reachable via the reflog.
If I expire unreachable objects from the reflog, then a simple git fsck will now show this commit as dangling.
However, assume I didn't expire the reflog. If I run git fsck --lost-found, Git now lists this commit as dangling, even though it still exists in the reflog.
From what I could find in the docs, nothing is said about --lost-found redefining what constitutes a dangling commit, or any other implied exception.
My question is, are (un?)reachable commits in the reflog dangling or not? If not, why does the --lost-found flag make them so?