mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <>
To: Junio C Hamano <>
Cc: "SZEDER Gábor" <>, "Git List" <>
Subject: Re: git format-patch --range-diff bug?
Date: Thu, 12 Nov 2020 13:32:42 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Nov 12, 2020 at 12:57 PM Junio C Hamano <> wrote:
> SZEDER Gábor <> writes:
> >       git range-diff v1...v2 &&
> >       git format-patch -1 --range-diff=v1...v2 v2 &&
> The other day I did something similar and ended up with
>         git format-patch --range-diff=v1 v1..v2
> Would it help not to use the three-dot form?  From my reading of
> "git format-patch --range-diff=<previous>" description, it only
> needs to give a single range (i.e. previous side of series of
> commits) as the other range to be compared are by definition the
> patches you are producing, while v1...v2 syntax is to give two
> ranges with one option.  So...

Indeed. It's not clear (at least to me) how git-format-patch's
--range-diff option should interpret a 3-dot range, thus the
implementation explicitly supports only a single revision or a 2-dot
range, and the documentation reflects this.

It turns out, as you discovered, that the implementation is a bit
deficient in that it doesn't outright reject a 3-dot range, and
instead gets tripped up by:

     int prev_is_range = !!strstr(prev, "..");

which accidentally also matches a 3-dot range, with the result that
the 3-dot range gets passed into the lower-level range-diff machinery
which then forwards the 3-dot range to git-log. The git-range-diff
command, on the other hand, interprets a 3-dot range manually so such
a range doesn't make it down to the lower-level range-diff machinery.

I haven't fully thought it through yet, but at this point, the best
"fix" likely would be for `git format-patch --range-diff` to error out
when it sees a 3-dot range. (Unless there is some other intuitive
interpretation of a 3-dot range which escapes me.)

  reply	other threads:[~2020-11-12 18:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 17:43 git format-patch --range-diff bug? SZEDER Gábor
2020-11-12 17:57 ` Junio C Hamano
2020-11-12 18:32   ` Eric Sunshine [this message]
2020-11-12 18:59     ` Junio C Hamano
2020-11-12 20:06       ` Eric Sunshine

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:

  List information:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

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 read-only IMAP folder(s) and NNTP newsgroup(s).