On Sat, Dec 17, 2016 at 4:28 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> David Turner <novalis@xxxxxxxxxxx> writes:
>
>> I'm a bit confused by the message "disabling bitmap writing, as some
>> objects are not being packed". I see it the my gc.log file on my git
>> server.
>
>> 1. Its presence in the gc.log file prevents future automatic garbage
>> collection. This seems bad. I understand the desire to avoid making
>> things worse if a past gc has run into issues. But this warning is
>> non-fatal; the only consequence is that many operations get slower. But
>> a lack of gc when there are too many packs causes that consequence too
>> (often a much worse slowdown than would be caused by the missing
>> bitmap).
>>
>> So I wonder if it would be better for auto gc to grep gc.log for fatal
>> errors (as opposed to warnings) and only skip running if any are found.
>> Alternately, we could simply put warnings into gc.log.warning and
>> reserve gc.log for fatal errors. I'm not sure which would be simpler.
>
> I am not sure if string matching is really a good idea, as I'd
> assume that these messages are eligible for i18n.
And we can't grep for fatal errors anyway. The problem that led to
329e6e8794 was this line
warning: There are too many unreachable loose objects; run 'git
prune' to remove them.
which is not fatal.
> 329e6e8794 ("gc: save log from daemonized gc --auto and print it
> next time", 2015-09-19) wanted to notice that auto-gc is not
> making progress and used the presense of error messages as a cue.
> In your case, I think the auto-gc _is_ making progress, reducing
> number of loose objects in the repository or consolidating many
> packfiles into one
Yeah the key point is making progress, and to reliably detect that we
need some way for all the commands that git-gc executes to tell it
about that, git-repack in this particular case but...
> and the message is only about the fact that
> packing is punting and not producing a bitmap as you asked, which
> is different from not making any progress. I do not think log vs
> warn is a good criteria to tell them apart, either.
>
> In any case, as the error message asks the user to do, the user
> eventually wants to correct the root cause before removing the
> gc.log; I am not sure report_last_gc_error() is the place to correct
> this in the first place.
>
>> 2. I don't understand what would cause that message. That is, what bad
>> thing am I doing that I should stop doing? I've briefly skimmed the
>> code and commit message, but the answer isn't leaping out at me.
>
> Enabling bitmap generation for incremental packing that does not
> cram everything into a single pack is triggering it, I would
> presume. Perhaps we should ignore -b option in most of the cases
> and enable it only for "repack -a -d -f" codepath? Or detect that
> we are being run from "gc --auto" and automatically disable -b?
... since we have to change down in git-repack for that, perhaps doing
this is better. We can pass --auto (or something) to repack to tell it
about this special caller, so it only prints something to stderr in
serious cases.
Or we detect cases where background gc'ing won't work well and always
do it in foreground (e.g. when bitmap generation is enabled).
> I have a feeling that an approach along that line is closer to the
> real solution than tweaking report_last_gc_error() and trying to
> deduce if we are making any progress.
--
Duy