QA when using git

1. Q:
   remote:
   remote: error: The last gc run reported the following. Please correct the root cause
   remote: and remove gc.log.
   remote: Automatic cleanup will not be performed until the file is removed.
   remote:
   remote: warning: disabling bitmap writing, as some objects are not being packed
   A:
   from stackoverflow:
   https://stackoverflow.com/questions/45439561/git-warning-disabling-bitmap-writing

Performing a git push is returning the following messages 
after successfully sending changes to the remote.

error: The last gc run reported the following. 
Please correct the root cause and remove gc.log.
Automatic cleanup will not be performed 
until the file is removed.

warning: disabling bitmap writing, 
as some objects are not being packed
Usually when the garbage collector 
returns warnings a git prune fixes it. 
Both that and git gc --aggressive haven't fixed this issue 
and don't return any errors or warnings. 
The file .git/gc.log doesn't exist.

This is a very large repo hosted on a private Bitbucket server.

What does "disabling bitmap writing, 
as some objects are not being packed" mean and 
how do we fix it? Where is the gc.log file?

git
bitbucket
share  improve this question  follow 
edited Aug 7 '18 at 13:40
asked Aug 1 '17 at 13:41

Matt S
I've seen gc.log before, 
that's located in the .git directory of the repo. 
I've never seen the bitmap warning before though.
 (Also, hi Matt. :) – Michael Louis Thaler Aug 1 '17 at 14:36
Hey, Michael! I can't see any gc.log in the .git 
or .git/logs directory. Even find . -iname gc.log 
returns nothing. – Matt S Aug 1 '17 at 14:44
Is the gc.log on the remote server? – o11c Oct 10 '17 at 22:05
@o11c No. I did once see it locally in another situation, 
but never when this warning comes up. – Matt S Oct 11 '17 at 13:14
add a comment
1 Answer

3

The gc.log file is left behind by a git gc --auto 
when it wants to report something (anything, at all, 
the problem being that git gc --auto was spun off in the background and has nowhere to report to, 
other than this log file).

As for the warning itself: bitmaps are used to 
speed up object traversal (i.e., to optimize server performance). This only works if all the objects 
are actually in the pack, 
which is what that warning means.

It's not clear to me 
why some objects are not being packed. 
The message comes from add_object_entry in 
builtin/pack-objects.c, 
if we don't want to put this object into the pack 
as determined by function want_object_in_pack 
in the same file. That in turn depends on --local and 
whether there are .keep files maintaining previous packs.

Git versions 2.12.2 and 2.13.0 added 
a hack to ignore (and remove) stale gc.log files, 
since their presence disables further git gc --auto operations. If your Git is this new, 
it will remove those stale files 
when the log expires, which defaults to 24 hours (1.day). 
See the gc.logExpire description in the git config documentation.

share  improve this answer  follow 
answered Aug 1 '17 at 15:11

torek
This is very informative. I am on 2.13.3. 
If I run just git gc I see no warning or log file. 
Only when I pull down new changes. 
The log file is never there even if 
I set gc.logExpire explicitly to 1.day. 
– Matt S Aug 1 '17 at 15:41
1
A regular (not --auto) git gc has somewhere 
to report to, so it won't write a log file 
even if it complains. The trick would be to 
get a non-auto gc to occur 
when you can spot it, or catch the auto-gc failure very quickly. I suspect there's something else going 
on with alternate object stores or some such, 
but don't know what. 
– torek Aug 1 '17 at 15:43