Re: [PATCH 0/1] pack-bitmap.c: avoid exposing absolute paths
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Oct 26, 2022, 23:19 UTC
- Message-ID
- <221027.86czaeb1xt.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <Y1mp23NHB0qzKsPR@nand.local>
On Wed, Oct 26 2022, Taylor Blau wrote:
Show 19 quoted lines
> 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?