git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git Mailing list <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [WIP PATCH/RFC] Use a higher range-diff --creation-factor for format-patch
Date: Fri, 15 Mar 2019 20:21:17 +0100	[thread overview]
Message-ID: <87tvg49c5u.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CAPig+cRMiEcXVRYrgp+B3tcDreh41-a5_k0zABe+HNce0G=Cyw@mail.gmail.com>


On Fri, Mar 15 2019, Eric Sunshine wrote:

> On Fri, Mar 15, 2019 at 12:09 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
>> @@ -261,6 +261,10 @@ material (this may change in the future).
>> +Defaults to 90, whereas the linkgit:git-range-diff[1] default is
>> +60. It's assumed that you're submitting a new patch series & that we
>> +should try harder than normal to find similarities.
>
> My understanding was that the primary use-case of git-range-diff
> itself (which existed before the --range-diff option was added to
> git-format-patch) was to generate a "range diff" for a cover letter of
> a re-rolled series. So, I'm confused about why this tweaks the default
> value of one command but not the other.
>
>> diff --git a/range-diff.h b/range-diff.h
>> @@ -4,6 +4,7 @@
>>  #define RANGE_DIFF_CREATION_FACTOR_DEFAULT 60
>> +#define RANGE_DIFF_CREATION_FACTOR_FORMAT_PATCH_DEFAULT 90
>
> The point of introducing RANGE_DIFF_CREATION_FACTOR_DEFAULT in the
> first place was to ensure that the default creation-factor didn't get
> out-of-sync between git-range-diff and git-format-patch., Thus,
> introducing this sort of inconsistency between the two would likely
> lead to confusion on the part of users. After all, --range-diff was
> added to git-format-patch merely as a convenience over having to run
> git-range-diff separately and copy/pasting its output into a cover
> letter generated by git-format-patch. If the two programs default to
> different values, then that "convenience equality" breaks down.
>
> So, I'm fairly negative on this change. However, that doesn't mean I
> would oppose tweaking the value shared between the two programs (and
> also the default used by GitGitGadget, if it specifies it manually),
> though I defer to Dscho in that regard.

I think that was the intention initially, but at least I'm now using
range-diff as a general comparison tool of different non-ff-branches,
e.g. the force-pushes to "pu".

I'd expect the tool in general to be used like that, whereas with
format-patch it's safe to say we're dealing with a re-roll of the same
thing.

Hence the hypothesis that for format-patch we can be more aggressive
about finding similarities.

  reply	other threads:[~2019-03-15 19:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-15 16:09 [WIP PATCH/RFC] Use a higher range-diff --creation-factor for format-patch Ævar Arnfjörð Bjarmason
2019-03-15 19:00 ` Eric Sunshine
2019-03-15 19:21   ` Ævar Arnfjörð Bjarmason [this message]
2019-03-21 11:22     ` Johannes Schindelin
2019-03-18  5:23   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tvg49c5u.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).