Two issues with mark_reachable_objects

[David Emett <dave@sp4m.net>]

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/