4

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?

Matt S
  • 14,976
  • 6
  • 57
  • 76
  • 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 01 '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 01 '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
  • 1
    Note: See also with Git 2.38 (Q3 2022) the new setting [`git -c push.useBitmaps=false push`](https://stackoverflow.com/a/73012939/6309), to disable packing for `git push`. No more warning in that case. – VonC Jul 17 '22 at 15:21

1 Answers1

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.

torek
  • 448,244
  • 59
  • 642
  • 775
  • 1
    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 01 '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 01 '17 at 15:43