Hi all,
I ran into an issue yesterday with a script that effectively does this:
set -e
git fetch origin refs/blah/blah
git checkout FETCH_HEAD
The checkout failed a few times with a "fatal: unable to read tree" error.
I noticed that this only happened when the fetch triggered an automatic GC at
the end. After a bit of digging I discovered two separate issues:
1) It seems that FETCH_HEAD is not considered a root by mark_reachable_objects.
2) If the bitmap_git branch in mark_reachable_objects is taken, the mark_recent
argument is ignored. This doesn't _completely_ break "git prune"'s --expire
option, as it turns out there is another explicit mtime check in
prune_object (prune.c). If that check passes this is not propagated to
referenced objects though. So even if a dangling commit is recent, a prune
can discard old objects it references.
(1) has been discussed before on this mailing list [1], but it doesn't look
like there was a conclusion.
I assume (2) is not intentional, given that "git gc --help" explicitly says
"Any object with modification time newer than the --prune date is kept, along
with everything reachable from it." Is it safe to just run the mark_recent
block after the bitmap_git block? Could add_unseen_recent_objects_to_traversal
just be called at the start of the bitmap_git block if mark_recent?
[1] https://lore.kernel.org/git/20160708025948.GA3226@x/
