Re: Re* [PATCH v4 0/3] advice: add "all" option to disable all hints

From: Eric Sunshine <sunshine@sunshineco.com>
Date: May 3, 2024, 21:24 UTC
Message-ID: <CAPig+cT-xk13jGEUmpT5QmwVYTxKNUZsu9xJ=Ph3h4AzKHg6pA@mail.gmail.com>
In-Reply-To: <xmqq4jbe64l9.fsf@gitster.g>

On Fri, May 3, 2024 at 4:08 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> It seems that Dscho was in agreement that format-patch's use case
> should try to be more aggressive at least back then.  In the message
> in the thread you pointed
>
>  https://lore.kernel.org/git/nycvar.QRO.7.76.6.1903211209280.41@tvgsbejvaqbjf.bet/
>
> he does not give us the exact reason why he does not think the "more
> aggressive" mode is not suitable for other use cases, though.

Having an answer to that question could be helpful.

> A similar thread was raised more recently:
>
>  https://lore.kernel.org/git/rq6919s9-qspp-rn6o-n704-r0400q10747r@tzk.qr/

I think I missed this thread.

Show 7 quoted lines

> Also, there was an attempt to clarify what the "factor" really
> meant, but we did not get a real conclusion other than the UNIT to
> measure the "factor" is called "percent" (without specifying what
> 100% is relative to, "percent" does not mean much to guide users
> to guess what the right value would be).
>
>  https://lore.kernel.org/git/85snn12q-po05-osqs-n1o0-n6040392q01q@tzk.qr/

I recall this discussion, as well as its followup (in which I proclaimed my continuing lack of understanding of what creation-factor really represents):

https://lore.kernel.org/git/CAPig+cRp4N=6EktoisKAH09aVAPkPgZfHJYcB5pJFJ-CUpBHFA@mail.gmail.com/

> So, yes, --creation-factor=<value> is messy, I think a very high
> value, much higher than the hardcoded default of 60, is more
> appropriate for use in format-patch, but we do not know what bad
> effect it would have if we used much higher default everywhere.

At this point in time, I'm not particularly against giving `git format-patch` its own default creation-factor.

My only worry (and perhaps it's very minor) is that separate default creation-factors for `git range-diff` and `git format-patch --range-diff` could catch the unwary off-guard when invoking `git range-diff` to manually check the difference between an old an new version of a series before finally invoking `git format-patch --range-diff` to actually create the patches for sending. (I've done this myself on a very few occasions, but perhaps not often enough to warrant the concern(?).)