Subject: Re: [PATCH 0/1] pack-bitmap.c: avoid exposing absolute paths

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Thu, 27 Oct 2022 01:19:16 +0200

On Wed, Oct 26 2022, Taylor Blau wrote:

> On Mon, Aug 29, 2022 at 10:48:03AM +0800, Teng Long wrote:
>> > If the "ignoring extra" is a totally expected situation (e.g. it is
>> > not suprising if we always ignore the bitmapfile in the alternate
>> > when we have our own), perhaps we should squelch the warning in such
>> > expected cases altogether (while warning other cases where we see
>> > more bitmap files than we expect to see, which may be an anomaly
>> > worth warning about), and that may be an improvement worth spending
>> > development cycles on, but I am not sure about this one.
>>
>> That's exactly good suggestion. In my opinion, I think to avoid the sensitive
>> warning and the same time we keep some information to let the users know "Oh,
>> there are some extra existing bitmaps we just ignored then maybe can do some
>> optimization works", but I think just remove the total warning here is
>> reasonable also, i'm good with it.
>
> I think that it is somewhat of a step backwards to remove it entirely,
> but let me qualify that a little bit.
>
> At GitHub, we actually *do* remove this warning entirely:

You at GitHub also added it entirely :) => fff42755efc (pack-bitmap: add
support for bitmap indexes, 2013-12-21).

Anyway, I'm fine with removing it. From skimming that commit it was
probably added for no particularly strong reason. But I found the
omission of "it was added in xyz commit" to be sometihng that could be
added to the commit message in this case, and....

> You could also imagine adding a configuration knob here to control
> whether or not the warning is shown, but I find that to be kind of
> gross.

FWIW I don't find that to be particularly gross. I think it's fine to
just delete it.

But isn't this a general sign that we should perhaps have different
output when "pack-objects" and the like is run "locally", v.s. when
we're running via some server process, and end up spewing a message out
that the user can't do anything about?