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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, 3 May 2024, Eric Sunshine wrote:

> On Fri, May 3, 2024 at 4:08 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > 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@xxxxxxxxxxxxxxxxx/
> >
> > 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.

Sure.

The `creation factor` essentially tells Git how confident the caller is that the
two provided commit ranges contain only matching pairs of patches, no
matter how different they look.

When calling `git format-patch --range-diff`, we can be _quite_ certain.
Not necessarily 100% (in which case the creation factor would need to be a
lot higher than 100), as it does happen that contributors have to drop a
patch or two, and add a patch or two, sometimes in the same iteration.

When calling `git range-diff` in general, we can be less certain about
that. In fact, users like me often call `git range-diff` to _determine_
whether there are obvious matches (for example, to see whether commits in
GitGitGadget PRs have corresponding commits in `seen`).

That difference in certainty is the entire reason why I contend that
`range-diff` and `format-patch --range-diff` need different defaults for
the creation factor.

> > A similar thread was raised more recently:
> >
> >  https://lore.kernel.org/git/rq6919s9-qspp-rn6o-n704-r0400q10747r@xxxxxx/
>
> I think I missed this thread.

Heh. I had forgotten about it.

Ciao,
Johannes

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux