The manpage for git gc says: > git gc tries very hard to be safe about the garbage it collects. In > particular, it will keep not only objects referenced by your current > set of branches and tags, but also objects referenced by the index, > remote-tracking branches, refs saved by git filter-branch in > refs/original/, or reflogs (which may reference commits in branches > that were later amended or rewound).
gc, repack, and anything else that uses the machinery in reachable.c will also check HEAD, to include objects only reachable from a detached HEAD (which the manpage should document). However, unreachable.c does not check any other ref that sits directly in the .git directory, such as MERGE_HEAD, FETCH_HEAD, or CHERRY_PICK_HEAD. To test this, try creating a new empty repository with "git init repo ; cd repo", then use "git fetch URL" to fetch a repository into FETCH_HEAD, then run "git repack -a -d -f", and then "git show FETCH_HEAD". This similarly affects "git gc", which will unpack all the objects from the pack and leave them loose. This could result in data loss, if a user expected that having an object referenced from those places would protect it from pruning. I think the right fix for this would involve having mark_reachable_objects in reachable.c add all refs that match .git/*HEAD, not just .git/HEAD itself. (I'd suggest matching .git/*HEAD rather than hardcoding the list of "special" refs, to provide compatibility with any other tool or future version of git that introduces another such ref.) This seems fairly easily done with a new variant of do_head_ref that includes all such refs, along with a one-line change to mark_reachable_objects to use it. Does this seem like a reasonable approach? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
