Junio C Hamano <gitster@xxxxxxxxx> writes: > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > >> different. Aren't both commands addressing the same use-case of >> comparing one version of a series against a subsequent version? In >> your response[3], you seemed to agree with that observation and >> suggested instead simply increasing the default creation factor for >> both commands (which sounds reasonable to me). > > I think Dscho's use case was compare only single updated series of > his with seen that has tons of irrelevant other patches, to have the > command sift the patches belong to other topics away while making > comparison with the older incarnation of his topic. I never use the > command for such a comparison, but I can imagine that in such a > context lower criteria may help reduce false matches of his new > commits with unrelated commits on 'seen'. 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. A similar thread was raised more recently: https://lore.kernel.org/git/rq6919s9-qspp-rn6o-n704-r0400q10747r@xxxxxx/ 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@xxxxxx/ 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.
