range-diff: add a --no-patch option to show a summary
diff mbox series

Message ID 20181105200650.31177-1-avarab@gmail.com
State New
Headers show
Series
  • range-diff: add a --no-patch option to show a summary
Related show

Commit Message

Ævar Arnfjörð Bjarmason Nov. 5, 2018, 8:06 p.m. UTC
Add a --no-patch option which shows which changes got removed, added
or moved etc., without showing the diff associated with them.

This allows for using range-diff as a poor man's "shortlog" for
force-pushed branches to see what changed without getting into the
details of what specifically. E.g. diffing the latest forced-push to
"pu" gives us:

    $ ./git-range-diff --no-patch b58974365b...711aaa392f | head -n 10
     -:  ---------- >  1:  b613de67c4 diff: differentiate error handling in parse_color_moved_ws
    28:  c731affab0 !  2:  23c4bbe28e build: link with curl-defined linker flags
     -:  ---------- >  3:  14f74d5907 git-worktree.txt: correct linkgit command name
     -:  ---------- >  4:  29d51e214c sequencer.c: remove a stray semicolon
     -:  ---------- >  5:  b7845cebc0 tree-walk.c: fix overoptimistic inclusion in :(exclude) matching
     -:  ---------- >  6:  1a550529b1 t/t7510-signed-commit.sh: Add %GP to custom format checks
     -:  ---------- >  7:  1e690847d1 t/t7510-signed-commit.sh: add signing subkey to Eris Discordia key
     9:  d13ecb7d81 !  8:  d8ad847421 Add a base implementation of SHA-256 support
    10:  3f0382eef8 =  9:  cdae1d391c sha256: add an SHA-256 implementation using libgcrypt
    11:  2422fd4227 = 10:  7d81aa0857 hash: add an SHA-256 implementation using OpenSSL

That would print a total of 44 lines of output, but the full
range-diff output with --patch is 460 lines.

I thought of implementing --stat too. It would be neat if passing
DIFF_FORMAT_DIFFSTAT just worked, but using that shows the underlying
implementation details of how range-diff works, instead of a useful
diffstat. So I'll leave that to a future change. Such a feature should
be something like a textual summary of the --patch output itself,
e.g.:

    N hunks, X insertions(+), Y deletions(-)

This change doesn't update git-format-patch with a --no-patch
option. That can be added later similar to how format-patch first
learned --range-diff, and then --creation-factor in
8631bf1cdd ("format-patch: add --creation-factor tweak for
--range-diff", 2018-07-22). I don't see why anyone would want this for
format-patch, it pretty much defeats the point of range-diff.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 Documentation/git-range-diff.txt |  4 +++
 builtin/log.c                    |  2 +-
 builtin/range-diff.c             |  5 +++-
 log-tree.c                       |  2 +-
 range-diff.c                     |  6 ++++-
 range-diff.h                     |  1 +
 t/t3206-range-diff.sh            | 45 ++++++++++++++++++++++++++++++++
 7 files changed, 61 insertions(+), 4 deletions(-)

Comments

Eric Sunshine Nov. 5, 2018, 8:26 p.m. UTC | #1
On Mon, Nov 5, 2018 at 3:07 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> Add a --no-patch option which shows which changes got removed, added
> or moved etc., without showing the diff associated with them.

This option existed in the very first version[1] of range-diff (then
called branch-diff) implemented by Dscho, although it was called
--no-patches (with an "es"), which it inherited from tbdiff. I think
someone (possibly me) pointed out that --no-patch (sans "es") would be
more consistent with existing Git options. I don't recall why Dscho
removed the option during the re-rolls, but the explanation may be in
that thread.

I was also wondering if --summarize or --summary-only might be a
better name, describing the behavior at a higher level, but since
there is precedent for --no-patch (or --no-patches in tbdiff), perhaps
the name is fine as is.

The patch itself looks okay.

[1]: https://public-inbox.org/git/8bc517e35d4842f8d9d98f3b99adb9475d6db2d2.1525361419.git.johannes.schindelin@gmx.de/
Ævar Arnfjörð Bjarmason Nov. 5, 2018, 9 p.m. UTC | #2
On Mon, Nov 05 2018, Eric Sunshine wrote:

> On Mon, Nov 5, 2018 at 3:07 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> Add a --no-patch option which shows which changes got removed, added
>> or moved etc., without showing the diff associated with them.
>
> This option existed in the very first version[1] of range-diff (then
> called branch-diff) implemented by Dscho, although it was called
> --no-patches (with an "es"), which it inherited from tbdiff. I think
> someone (possibly me) pointed out that --no-patch (sans "es") would be
> more consistent with existing Git options. I don't recall why Dscho
> removed the option during the re-rolls, but the explanation may be in
> that thread.

Thanks for digging. Big thread, not going to re-read it now. I'd just
like to have this.

> I was also wondering if --summarize or --summary-only might be a
> better name, describing the behavior at a higher level, but since
> there is precedent for --no-patch (or --no-patches in tbdiff), perhaps
> the name is fine as is.

I think we should aim to keep a 1=1 mapping between range-diff and
log/show options when possible, even though the output might have a
slightly different flavor as my 4th paragraph discussing a potential
--stat talks about.

E.g. I can imagine that range-diff --no-patch --stat --summary would not
show the patch, but a stat as described there, plus e.g. a "create
mode..." if applicable.

This change implements only a tiny fraction of that, but it would be
very neat if we supported more stuff, and showed it in range-diff-y way,
e.g. some compact format showing:

    1 file changed, 3->2 insertions(+), 10->9 deletions(-)
    create mode 100(6 -> 7)44 new-executable

> The patch itself looks okay.
>
> [1]: https://public-inbox.org/git/8bc517e35d4842f8d9d98f3b99adb9475d6db2d2.1525361419.git.johannes.schindelin@gmx.de/
Junio C Hamano Nov. 6, 2018, 4:16 a.m. UTC | #3
Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> This change doesn't update git-format-patch with a --no-patch
> option. That can be added later similar to how format-patch first
> learned --range-diff, and then --creation-factor in
> 8631bf1cdd ("format-patch: add --creation-factor tweak for
> --range-diff", 2018-07-22). I don't see why anyone would want this for
> format-patch, it pretty much defeats the point of range-diff.

I am OK not to have this option integrated to format-patch from day
one, but I do not think it is a good idea to hint that it should not
be done later.

Does it defeats the point of range-diff to omit the patch part in
the context of the cover letter?  How?

I think the output with this option is a good addition to the cover
letter as an abbreviated form (as opposed to the full range-diff,
whose support was added earlier) that gives an overview.

Calling this --[no-]patch might make it harder to integrate it to
format-patch later, though.  I suspect that people would expect
"format-patch --no-patch ..." to omit both the patch part of the
range-diff output *AND* the patch that should be applied to the
codebase (it of course would defeat the point of format-patch, so
today's format-patch would not pay attention to --no-patch, of
course).  We need to be careful not to break that when it happens.
Eric Sunshine Nov. 6, 2018, 5:15 a.m. UTC | #4
On Mon, Nov 5, 2018 at 11:17 PM Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
> > This change doesn't update git-format-patch with a --no-patch
> > option. That can be added later similar to how format-patch first
> > learned --range-diff, and then --creation-factor in
> > 8631bf1cdd ("format-patch: add --creation-factor tweak for
> > --range-diff", 2018-07-22). I don't see why anyone would want this for
> > format-patch, it pretty much defeats the point of range-diff.
>
> Does it defeats the point of range-diff to omit the patch part in
> the context of the cover letter?  How?
>
> I think the output with this option is a good addition to the cover
> letter as an abbreviated form (as opposed to the full range-diff,
> whose support was added earlier) that gives an overview.

I had the same response when reading the commit message but didn't
vocalize it. I could see people wanting to suppress the 'patch' part
of the embedded range-diff in a cover letter (though probably not as
commentary in a single-patch).

> Calling this --[no-]patch might make it harder to integrate it to
> format-patch later, though.  I suspect that people would expect
> "format-patch --no-patch ..." to omit both the patch part of the
> range-diff output *AND* the patch that should be applied to the
> codebase (it of course would defeat the point of format-patch, so
> today's format-patch would not pay attention to --no-patch, of
> course).  We need to be careful not to break that when it happens.

Same concern on my side, which is why I was thinking of other, less
confusing, names, such as --summarize or such, though even that is too
general against the full set of git-format-patch options. It could,
perhaps be a separate option, say, "git format-patch
--range-changes=<prev>" or something, which would embed the equivalent
of "git range-diff --no-patch <prev>...<current>" in the cover letter.
Junio C Hamano Nov. 6, 2018, 5:57 a.m. UTC | #5
Eric Sunshine <sunshine@sunshineco.com> writes:

>> Calling this --[no-]patch might make it harder to integrate it to
>> format-patch later, though.  I suspect that people would expect
>> "format-patch --no-patch ..." to omit both the patch part of the
>> range-diff output *AND* the patch that should be applied to the
>> codebase (it of course would defeat the point of format-patch, so
>> today's format-patch would not pay attention to --no-patch, of
>> course).  We need to be careful not to break that when it happens.
>
> Same concern on my side, which is why I was thinking of other, less
> confusing, names, such as --summarize or such, though even that is too
> general against the full set of git-format-patch options. It could,
> perhaps be a separate option, say, "git format-patch
> --range-changes=<prev>" or something, which would embed the equivalent
> of "git range-diff --no-patch <prev>...<current>" in the cover letter.

I actually am perfectly fine with --no-patch.  My "concern" was
merely that we should be careful to make sure that we do not stop
producing patches when we plug this patch to format-patch when
"format-patch --no-patch" is given; rather, it should only suppress
the patch part of range-diff shown in the cover letter.
Ævar Arnfjörð Bjarmason Nov. 6, 2018, 8:36 a.m. UTC | #6
On Tue, Nov 06 2018, Eric Sunshine wrote:

> On Mon, Nov 5, 2018 at 11:17 PM Junio C Hamano <gitster@pobox.com> wrote:
>> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>> > This change doesn't update git-format-patch with a --no-patch
>> > option. That can be added later similar to how format-patch first
>> > learned --range-diff, and then --creation-factor in
>> > 8631bf1cdd ("format-patch: add --creation-factor tweak for
>> > --range-diff", 2018-07-22). I don't see why anyone would want this for
>> > format-patch, it pretty much defeats the point of range-diff.
>>
>> Does it defeats the point of range-diff to omit the patch part in
>> the context of the cover letter?  How?
>>
>> I think the output with this option is a good addition to the cover
>> letter as an abbreviated form (as opposed to the full range-diff,
>> whose support was added earlier) that gives an overview.
>
> I had the same response when reading the commit message but didn't
> vocalize it. I could see people wanting to suppress the 'patch' part
> of the embedded range-diff in a cover letter (though probably not as
> commentary in a single-patch).
>
>> Calling this --[no-]patch might make it harder to integrate it to
>> format-patch later, though.  I suspect that people would expect
>> "format-patch --no-patch ..." to omit both the patch part of the
>> range-diff output *AND* the patch that should be applied to the
>> codebase (it of course would defeat the point of format-patch, so
>> today's format-patch would not pay attention to --no-patch, of
>> course).  We need to be careful not to break that when it happens.
>
> Same concern on my side, which is why I was thinking of other, less
> confusing, names, such as --summarize or such, though even that is too
> general against the full set of git-format-patch options. It could,
> perhaps be a separate option, say, "git format-patch
> --range-changes=<prev>" or something, which would embed the equivalent
> of "git range-diff --no-patch <prev>...<current>" in the cover letter.

Maybe this was discussed more when this range-diff format-patch
integration was submitted, I wasn't following that closely:

Looking at this more carefully it seems like quite a design limitation
that we're conflating the options for format-patch itself and for the
range-diff invocation it makes.

Wouldn't it be better to make all these options
e.g. --range-diff-creation-factor=*, --range-diff-no-patch,
--range-diff-U1 etc. Now there's no way to say supply a different
-U<ctx> for the range-diff & the patches themselves which seems like a
semi-common use-case.

Doing that seems to be a matter of teaching setup_revisions() to
accumulate unknown options, then parsing those into their own diffopts
with the "range-diff-" prefix stripped and handing that data off to the
range-diff machinery, not the parsed options for range-diff itself as
happens now.
Johannes Schindelin Nov. 6, 2018, 10:43 a.m. UTC | #7
Hi,

On Mon, 5 Nov 2018, Ævar Arnfjörð Bjarmason wrote:

> On Mon, Nov 05 2018, Eric Sunshine wrote:
>
> > On Mon, Nov 5, 2018 at 3:07 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> >> Add a --no-patch option which shows which changes got removed, added
> >> or moved etc., without showing the diff associated with them.
> >
> > This option existed in the very first version[1] of range-diff (then
> > called branch-diff) implemented by Dscho, although it was called
> > --no-patches (with an "es"), which it inherited from tbdiff. I think
> > someone (possibly me) pointed out that --no-patch (sans "es") would be
> > more consistent with existing Git options. I don't recall why Dscho
> > removed the option during the re-rolls, but the explanation may be in
> > that thread.
>
> Thanks for digging. Big thread, not going to re-read it now. I'd just
> like to have this.

In my hands, the well-documented `-s` option works (see e.g.
https://git-scm.com/docs/git-diff#git-diff--s), although I have to admit
that the `git-range-diff` manual does not talk about the diff-options.

And for the record, for me, `git range-diff A...B --no-patch` *already*
works.

Ciao,
Dscho

>
> > I was also wondering if --summarize or --summary-only might be a
> > better name, describing the behavior at a higher level, but since
> > there is precedent for --no-patch (or --no-patches in tbdiff), perhaps
> > the name is fine as is.
>
> I think we should aim to keep a 1=1 mapping between range-diff and
> log/show options when possible, even though the output might have a
> slightly different flavor as my 4th paragraph discussing a potential
> --stat talks about.
>
> E.g. I can imagine that range-diff --no-patch --stat --summary would not
> show the patch, but a stat as described there, plus e.g. a "create
> mode..." if applicable.
>
> This change implements only a tiny fraction of that, but it would be
> very neat if we supported more stuff, and showed it in range-diff-y way,
> e.g. some compact format showing:
>
>     1 file changed, 3->2 insertions(+), 10->9 deletions(-)
>     create mode 100(6 -> 7)44 new-executable
>
> > The patch itself looks okay.
> >
> > [1]: https://public-inbox.org/git/8bc517e35d4842f8d9d98f3b99adb9475d6db2d2.1525361419.git.johannes.schindelin@gmx.de/
>
Ævar Arnfjörð Bjarmason Nov. 6, 2018, 4:01 p.m. UTC | #8
On Tue, Nov 06 2018, Johannes Schindelin wrote:

> Hi,
>
> On Mon, 5 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Mon, Nov 05 2018, Eric Sunshine wrote:
>>
>> > On Mon, Nov 5, 2018 at 3:07 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> >> Add a --no-patch option which shows which changes got removed, added
>> >> or moved etc., without showing the diff associated with them.
>> >
>> > This option existed in the very first version[1] of range-diff (then
>> > called branch-diff) implemented by Dscho, although it was called
>> > --no-patches (with an "es"), which it inherited from tbdiff. I think
>> > someone (possibly me) pointed out that --no-patch (sans "es") would be
>> > more consistent with existing Git options. I don't recall why Dscho
>> > removed the option during the re-rolls, but the explanation may be in
>> > that thread.
>>
>> Thanks for digging. Big thread, not going to re-read it now. I'd just
>> like to have this.
>
> In my hands, the well-documented `-s` option works (see e.g.
> https://git-scm.com/docs/git-diff#git-diff--s), although I have to admit
> that the `git-range-diff` manual does not talk about the diff-options.
>
> And for the record, for me, `git range-diff A...B --no-patch` *already*
> works.

Neither of those works for me without my patch. E.g.

    ./git-range-diff -s 711aaa392f...a5ba8f2101
    ./git-range-diff --no-patch 711aaa392f...a5ba8f2101

This is on current next, 2.19.1.1182.g4ecb1133ce. What version are you
on?

>>
>> > I was also wondering if --summarize or --summary-only might be a
>> > better name, describing the behavior at a higher level, but since
>> > there is precedent for --no-patch (or --no-patches in tbdiff), perhaps
>> > the name is fine as is.
>>
>> I think we should aim to keep a 1=1 mapping between range-diff and
>> log/show options when possible, even though the output might have a
>> slightly different flavor as my 4th paragraph discussing a potential
>> --stat talks about.
>>
>> E.g. I can imagine that range-diff --no-patch --stat --summary would not
>> show the patch, but a stat as described there, plus e.g. a "create
>> mode..." if applicable.
>>
>> This change implements only a tiny fraction of that, but it would be
>> very neat if we supported more stuff, and showed it in range-diff-y way,
>> e.g. some compact format showing:
>>
>>     1 file changed, 3->2 insertions(+), 10->9 deletions(-)
>>     create mode 100(6 -> 7)44 new-executable
>>
>> > The patch itself looks okay.
>> >
>> > [1]: https://public-inbox.org/git/8bc517e35d4842f8d9d98f3b99adb9475d6db2d2.1525361419.git.johannes.schindelin@gmx.de/
>>
Johannes Schindelin Nov. 7, 2018, 10:34 a.m. UTC | #9
Hi Ævar,

On Tue, 6 Nov 2018, Ævar Arnfjörð Bjarmason wrote:

> On Tue, Nov 06 2018, Johannes Schindelin wrote:
> 
> > On Mon, 5 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> >
> >> On Mon, Nov 05 2018, Eric Sunshine wrote:
> >>
> >> > On Mon, Nov 5, 2018 at 3:07 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> >> >> Add a --no-patch option which shows which changes got removed, added
> >> >> or moved etc., without showing the diff associated with them.
> >> >
> >> > This option existed in the very first version[1] of range-diff (then
> >> > called branch-diff) implemented by Dscho, although it was called
> >> > --no-patches (with an "es"), which it inherited from tbdiff. I think
> >> > someone (possibly me) pointed out that --no-patch (sans "es") would be
> >> > more consistent with existing Git options. I don't recall why Dscho
> >> > removed the option during the re-rolls, but the explanation may be in
> >> > that thread.
> >>
> >> Thanks for digging. Big thread, not going to re-read it now. I'd just
> >> like to have this.
> >
> > In my hands, the well-documented `-s` option works (see e.g.
> > https://git-scm.com/docs/git-diff#git-diff--s), although I have to admit
> > that the `git-range-diff` manual does not talk about the diff-options.
> >
> > And for the record, for me, `git range-diff A...B --no-patch` *already*
> > works.
> 
> Neither of those works for me without my patch. E.g.
> 
>     ./git-range-diff -s 711aaa392f...a5ba8f2101
>     ./git-range-diff --no-patch 711aaa392f...a5ba8f2101
>
> This is on current next, 2.19.1.1182.g4ecb1133ce. What version are you
> on?

I tried it with git version 2.19.0.windows.1.

To verify, I repeated this with `next` (git version
2.19.1.1215.g8438c0b2453a):

./git range-diff -s 711aaa392f...a5ba8f2101
fatal: unrecognized argument: --output-indicator-new=>
error: could not parse log for 'a5ba8f2101..711aaa392f'

Which means that something broke rather dramatically between
v2.19.0.windows.1 and 8438c0b2453a.

Ciao,
Dscho

> 
> >>
> >> > I was also wondering if --summarize or --summary-only might be a
> >> > better name, describing the behavior at a higher level, but since
> >> > there is precedent for --no-patch (or --no-patches in tbdiff), perhaps
> >> > the name is fine as is.
> >>
> >> I think we should aim to keep a 1=1 mapping between range-diff and
> >> log/show options when possible, even though the output might have a
> >> slightly different flavor as my 4th paragraph discussing a potential
> >> --stat talks about.
> >>
> >> E.g. I can imagine that range-diff --no-patch --stat --summary would not
> >> show the patch, but a stat as described there, plus e.g. a "create
> >> mode..." if applicable.
> >>
> >> This change implements only a tiny fraction of that, but it would be
> >> very neat if we supported more stuff, and showed it in range-diff-y way,
> >> e.g. some compact format showing:
> >>
> >>     1 file changed, 3->2 insertions(+), 10->9 deletions(-)
> >>     create mode 100(6 -> 7)44 new-executable
> >>
> >> > The patch itself looks okay.
> >> >
> >> > [1]: https://public-inbox.org/git/8bc517e35d4842f8d9d98f3b99adb9475d6db2d2.1525361419.git.johannes.schindelin@gmx.de/
> >>
>
Johannes Schindelin Nov. 7, 2018, 10:43 a.m. UTC | #10
Hi Ævar,

On Wed, 7 Nov 2018, Johannes Schindelin wrote:

> On Tue, 6 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> 
> > On Tue, Nov 06 2018, Johannes Schindelin wrote:
> > 
> > > On Mon, 5 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> > >
> > >> On Mon, Nov 05 2018, Eric Sunshine wrote:
> > >>
> > >> > On Mon, Nov 5, 2018 at 3:07 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> > >> >> Add a --no-patch option which shows which changes got removed, added
> > >> >> or moved etc., without showing the diff associated with them.
> > >> >
> > >> > This option existed in the very first version[1] of range-diff (then
> > >> > called branch-diff) implemented by Dscho, although it was called
> > >> > --no-patches (with an "es"), which it inherited from tbdiff. I think
> > >> > someone (possibly me) pointed out that --no-patch (sans "es") would be
> > >> > more consistent with existing Git options. I don't recall why Dscho
> > >> > removed the option during the re-rolls, but the explanation may be in
> > >> > that thread.
> > >>
> > >> Thanks for digging. Big thread, not going to re-read it now. I'd just
> > >> like to have this.
> > >
> > > In my hands, the well-documented `-s` option works (see e.g.
> > > https://git-scm.com/docs/git-diff#git-diff--s), although I have to admit
> > > that the `git-range-diff` manual does not talk about the diff-options.
> > >
> > > And for the record, for me, `git range-diff A...B --no-patch` *already*
> > > works.
> > 
> > Neither of those works for me without my patch. E.g.
> > 
> >     ./git-range-diff -s 711aaa392f...a5ba8f2101
> >     ./git-range-diff --no-patch 711aaa392f...a5ba8f2101
> >
> > This is on current next, 2.19.1.1182.g4ecb1133ce. What version are you
> > on?
> 
> I tried it with git version 2.19.0.windows.1.
> 
> To verify, I repeated this with `next` (git version
> 2.19.1.1215.g8438c0b2453a):
> 
> ./git range-diff -s 711aaa392f...a5ba8f2101
> fatal: unrecognized argument: --output-indicator-new=>
> error: could not parse log for 'a5ba8f2101..711aaa392f'
> 
> Which means that something broke rather dramatically between
> v2.19.0.windows.1 and 8438c0b2453a.

Nevermind, this was solved by passing `--exec-path=$PWD`. And *now* I can
reproduce your finding.

Ciao,
Dscho
Johannes Schindelin Nov. 7, 2018, 10:55 a.m. UTC | #11
Hi Ævar,

On Wed, 7 Nov 2018, Johannes Schindelin wrote:

> On Wed, 7 Nov 2018, Johannes Schindelin wrote:
> 
> > On Tue, 6 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> > 
> > > On Tue, Nov 06 2018, Johannes Schindelin wrote:
> > > 
> > > > On Mon, 5 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> > > >
> > > >> On Mon, Nov 05 2018, Eric Sunshine wrote:
> > > >>
> > > >> > On Mon, Nov 5, 2018 at 3:07 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> > > >> >> Add a --no-patch option which shows which changes got removed, added
> > > >> >> or moved etc., without showing the diff associated with them.
> > > >> >
> > > >> > This option existed in the very first version[1] of range-diff (then
> > > >> > called branch-diff) implemented by Dscho, although it was called
> > > >> > --no-patches (with an "es"), which it inherited from tbdiff. I think
> > > >> > someone (possibly me) pointed out that --no-patch (sans "es") would be
> > > >> > more consistent with existing Git options. I don't recall why Dscho
> > > >> > removed the option during the re-rolls, but the explanation may be in
> > > >> > that thread.
> > > >>
> > > >> Thanks for digging. Big thread, not going to re-read it now. I'd just
> > > >> like to have this.
> > > >
> > > > In my hands, the well-documented `-s` option works (see e.g.
> > > > https://git-scm.com/docs/git-diff#git-diff--s), although I have to admit
> > > > that the `git-range-diff` manual does not talk about the diff-options.
> > > >
> > > > And for the record, for me, `git range-diff A...B --no-patch` *already*
> > > > works.
> > > 
> > > Neither of those works for me without my patch. E.g.
> > > 
> > >     ./git-range-diff -s 711aaa392f...a5ba8f2101
> > >     ./git-range-diff --no-patch 711aaa392f...a5ba8f2101
> > >
> > > This is on current next, 2.19.1.1182.g4ecb1133ce. What version are you
> > > on?
> > 
> > I tried it with git version 2.19.0.windows.1.
> > 
> > To verify, I repeated this with `next` (git version
> > 2.19.1.1215.g8438c0b2453a):
> > 
> > ./git range-diff -s 711aaa392f...a5ba8f2101
> > fatal: unrecognized argument: --output-indicator-new=>
> > error: could not parse log for 'a5ba8f2101..711aaa392f'
> > 
> > Which means that something broke rather dramatically between
> > v2.19.0.windows.1 and 8438c0b2453a.
> 
> Nevermind, this was solved by passing `--exec-path=$PWD`. And *now* I can
> reproduce your finding.

I've bisected this breakage down to 73a834e9e279 (range-diff: relieve
callers of low-level configuration burden, 2018-07-22). Eric, that's one
of your commits.

Ciao,
Dscho
Johannes Schindelin Nov. 7, 2018, 11:08 a.m. UTC | #12
Me again,

On Wed, 7 Nov 2018, Johannes Schindelin wrote:

> On Wed, 7 Nov 2018, Johannes Schindelin wrote:
> 
> > On Wed, 7 Nov 2018, Johannes Schindelin wrote:
> > 
> > > On Tue, 6 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> > > 
> > > > On Tue, Nov 06 2018, Johannes Schindelin wrote:
> > > > 
> > > > > On Mon, 5 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> > > > >
> > > > >> On Mon, Nov 05 2018, Eric Sunshine wrote:
> > > > >>
> > > > >> > On Mon, Nov 5, 2018 at 3:07 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> > > > >> >> Add a --no-patch option which shows which changes got removed, added
> > > > >> >> or moved etc., without showing the diff associated with them.
> > > > >> >
> > > > >> > This option existed in the very first version[1] of range-diff (then
> > > > >> > called branch-diff) implemented by Dscho, although it was called
> > > > >> > --no-patches (with an "es"), which it inherited from tbdiff. I think
> > > > >> > someone (possibly me) pointed out that --no-patch (sans "es") would be
> > > > >> > more consistent with existing Git options. I don't recall why Dscho
> > > > >> > removed the option during the re-rolls, but the explanation may be in
> > > > >> > that thread.
> > > > >>
> > > > >> Thanks for digging. Big thread, not going to re-read it now. I'd just
> > > > >> like to have this.
> > > > >
> > > > > In my hands, the well-documented `-s` option works (see e.g.
> > > > > https://git-scm.com/docs/git-diff#git-diff--s), although I have to admit
> > > > > that the `git-range-diff` manual does not talk about the diff-options.
> > > > >
> > > > > And for the record, for me, `git range-diff A...B --no-patch` *already*
> > > > > works.
> > > > 
> > > > Neither of those works for me without my patch. E.g.
> > > > 
> > > >     ./git-range-diff -s 711aaa392f...a5ba8f2101
> > > >     ./git-range-diff --no-patch 711aaa392f...a5ba8f2101
> > > >
> > > > This is on current next, 2.19.1.1182.g4ecb1133ce. What version are you
> > > > on?
> > > 
> > > I tried it with git version 2.19.0.windows.1.
> > > 
> > > To verify, I repeated this with `next` (git version
> > > 2.19.1.1215.g8438c0b2453a):
> > > 
> > > ./git range-diff -s 711aaa392f...a5ba8f2101
> > > fatal: unrecognized argument: --output-indicator-new=>
> > > error: could not parse log for 'a5ba8f2101..711aaa392f'
> > > 
> > > Which means that something broke rather dramatically between
> > > v2.19.0.windows.1 and 8438c0b2453a.
> > 
> > Nevermind, this was solved by passing `--exec-path=$PWD`. And *now* I can
> > reproduce your finding.
> 
> I've bisected this breakage down to 73a834e9e279 (range-diff: relieve
> callers of low-level configuration burden, 2018-07-22). Eric, that's one
> of your commits.

Okay, so I would really like to point you to this particular paragraph in
the manual page of `git range-diff` (just below
https://git-scm.com/docs/git-range-diff#git-range-diff-ltbasegtltrev1gtltrev2gt):

	`git range-diff` also accepts the regular diff options (see
	linkgit:git-diff[1]), most notably the `--color=[<when>]` and
	`--no-color` options. These options are used when generating the "diff
	between patches", i.e. to compare the author, commit message and diff of
	corresponding old/new commits. There is currently no means to tweak the
	diff options passed to `git log` when generating those patches.

So this was quite intentional, in particular with an eye on `--no-patch`.
Note also the commit message of c8c5e43ac3f9 (range-diff: also show the
diff between patches, 2018-08-13):

    Note also: while tbdiff accepts the `--no-patches` option to suppress
    these diffs between patches, we prefer the `-s` (or `--no-patch`)
    option that is automatically supported via our use of diff_opt_parse().

This was very, very intentional, as you can see, and it was pretty broken
by 73a834e. This here patch papers over that breakage, sadly I have too
much on my plate as it is, so I cannot wrap it up in a nice commit (nor
add a regression test, but you did that, nor investigate what else is
broken) and therefore I would be indebted if you could take this in your
custody:

diff --git a/range-diff.c b/range-diff.c
index 3dd2edda0176..014112ee401f 100644
--- a/range-diff.c
+++ b/range-diff.c
@@ -433,7 +433,8 @@ int show_range_diff(const char *range1, const char *range2,
 		struct strbuf indent = STRBUF_INIT;
 
 		memcpy(&opts, diffopt, sizeof(opts));
-		opts.output_format = DIFF_FORMAT_PATCH;
+		if (!opts.output_format)
+			opts.output_format = DIFF_FORMAT_PATCH;
 		opts.flags.suppress_diff_headers = 1;
 		opts.flags.dual_color_diffed_diffs = dual_color;
 		opts.output_prefix = output_prefix_cb;

Ciao,
Dscho

Patch
diff mbox series

diff --git a/Documentation/git-range-diff.txt b/Documentation/git-range-diff.txt
index f693930fdb..d0473cbcb1 100644
--- a/Documentation/git-range-diff.txt
+++ b/Documentation/git-range-diff.txt
@@ -57,6 +57,10 @@  to revert to color all lines according to the outer diff markers
 	See the ``Algorithm`` section below for an explanation why this is
 	needed.
 
+--no-patch::
+	Don't show the range-diff itself, only which patches are the
+	same or were added or removed etc.
+
 <range1> <range2>::
 	Compare the commits specified by the two ranges, where
 	`<range1>` is considered an older version of `<range2>`.
diff --git a/builtin/log.c b/builtin/log.c
index 061d4fd864..e063bcf2dd 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1096,7 +1096,7 @@  static void make_cover_letter(struct rev_info *rev, int use_stdout,
 	if (rev->rdiff1) {
 		fprintf_ln(rev->diffopt.file, "%s", rev->rdiff_title);
 		show_range_diff(rev->rdiff1, rev->rdiff2,
-				rev->creation_factor, 1, &rev->diffopt);
+				rev->creation_factor, 1, 1, &rev->diffopt);
 	}
 }
 
diff --git a/builtin/range-diff.c b/builtin/range-diff.c
index f01a0be851..70c2761751 100644
--- a/builtin/range-diff.c
+++ b/builtin/range-diff.c
@@ -16,11 +16,14 @@  int cmd_range_diff(int argc, const char **argv, const char *prefix)
 	int creation_factor = RANGE_DIFF_CREATION_FACTOR_DEFAULT;
 	struct diff_options diffopt = { NULL };
 	int simple_color = -1;
+	int patch = 1;
 	struct option options[] = {
 		OPT_INTEGER(0, "creation-factor", &creation_factor,
 			    N_("Percentage by which creation is weighted")),
 		OPT_BOOL(0, "no-dual-color", &simple_color,
 			    N_("use simple diff colors")),
+		OPT_BOOL('p', "patch", &patch,
+			 N_("show patch output")),
 		OPT_END()
 	};
 	int i, j, res = 0;
@@ -92,7 +95,7 @@  int cmd_range_diff(int argc, const char **argv, const char *prefix)
 	}
 
 	res = show_range_diff(range1.buf, range2.buf, creation_factor,
-			      simple_color < 1, &diffopt);
+			      simple_color < 1, patch, &diffopt);
 
 	strbuf_release(&range1);
 	strbuf_release(&range2);
diff --git a/log-tree.c b/log-tree.c
index 7a83e99250..843e3ef83b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -762,7 +762,7 @@  void show_log(struct rev_info *opt)
 		next_commentary_block(opt, NULL);
 		fprintf_ln(opt->diffopt.file, "%s", opt->rdiff_title);
 		show_range_diff(opt->rdiff1, opt->rdiff2,
-				opt->creation_factor, 1, &opt->diffopt);
+				opt->creation_factor, 1, 1, &opt->diffopt);
 
 		memcpy(&diff_queued_diff, &dq, sizeof(diff_queued_diff));
 	}
diff --git a/range-diff.c b/range-diff.c
index bd8083f2d1..c1bfa593ce 100644
--- a/range-diff.c
+++ b/range-diff.c
@@ -436,6 +436,7 @@  static struct strbuf *output_prefix_cb(struct diff_options *opt, void *data)
 
 int show_range_diff(const char *range1, const char *range2,
 		    int creation_factor, int dual_color,
+		    int patch,
 		    struct diff_options *diffopt)
 {
 	int res = 0;
@@ -453,7 +454,10 @@  int show_range_diff(const char *range1, const char *range2,
 		struct strbuf indent = STRBUF_INIT;
 
 		memcpy(&opts, diffopt, sizeof(opts));
-		opts.output_format = DIFF_FORMAT_PATCH;
+		if (patch)
+			opts.output_format = DIFF_FORMAT_PATCH;
+		else
+			opts.output_format = DIFF_FORMAT_NO_OUTPUT;
 		opts.flags.suppress_diff_headers = 1;
 		opts.flags.dual_color_diffed_diffs = dual_color;
 		opts.output_prefix = output_prefix_cb;
diff --git a/range-diff.h b/range-diff.h
index 190593f0c7..99bbc1cd9f 100644
--- a/range-diff.h
+++ b/range-diff.h
@@ -7,6 +7,7 @@ 
 
 int show_range_diff(const char *range1, const char *range2,
 		    int creation_factor, int dual_color,
+		    int patch,
 		    struct diff_options *diffopt);
 
 #endif
diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
index 6aae364171..8f8be0c57f 100755
--- a/t/t3206-range-diff.sh
+++ b/t/t3206-range-diff.sh
@@ -122,6 +122,17 @@  test_expect_success 'changed commit' '
 	test_cmp expected actual
 '
 
+test_expect_success 'changed commit --no-patch' '
+	git range-diff --no-color --no-patch topic...changed >actual &&
+	cat >expected <<-EOF &&
+	1:  4de457d = 1:  a4b3333 s/5/A/
+	2:  fccce22 = 2:  f51d370 s/4/A/
+	3:  147e64e ! 3:  0559556 s/11/B/
+	4:  a63e992 ! 4:  d966c5c s/12/B/
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'changed commit with sm config' '
 	git range-diff --no-color --submodule=log topic...changed >actual &&
 	cat >expected <<-EOF &&
@@ -151,6 +162,17 @@  test_expect_success 'changed commit with sm config' '
 	test_cmp expected actual
 '
 
+test_expect_success 'changed commit with sm config --no-patch' '
+	git range-diff --no-color --no-patch --submodule=log topic...changed >actual &&
+	cat >expected <<-EOF &&
+	1:  4de457d = 1:  a4b3333 s/5/A/
+	2:  fccce22 = 2:  f51d370 s/4/A/
+	3:  147e64e ! 3:  0559556 s/11/B/
+	4:  a63e992 ! 4:  d966c5c s/12/B/
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'no commits on one side' '
 	git commit --amend -m "new message" &&
 	git range-diff master HEAD@{1} HEAD
@@ -176,6 +198,17 @@  test_expect_success 'changed message' '
 	test_cmp expected actual
 '
 
+test_expect_success 'changed message --no-patch' '
+	git range-diff --no-color --no-patch topic...changed-message >actual &&
+	sed s/Z/\ /g >expected <<-EOF &&
+	1:  4de457d = 1:  f686024 s/5/A/
+	2:  fccce22 ! 2:  4ab067d s/4/A/
+	3:  147e64e = 3:  b9cb956 s/11/B/
+	4:  a63e992 = 4:  8add5f1 s/12/B/
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'dual-coloring' '
 	sed -e "s|^:||" >expect <<-\EOF &&
 	:<YELLOW>1:  a4b3333 = 1:  f686024 s/5/A/<RESET>
@@ -215,6 +248,18 @@  test_expect_success 'dual-coloring' '
 	test_cmp expect actual
 '
 
+test_expect_success 'dual-coloring --no-patch' '
+	sed -e "s|^:||" >expect <<-\EOF &&
+	:<YELLOW>1:  a4b3333 = 1:  f686024 s/5/A/<RESET>
+	:<RED>2:  f51d370 <RESET><YELLOW>!<RESET><GREEN> 2:  4ab067d<RESET><YELLOW> s/4/A/<RESET>
+	:<RED>3:  0559556 <RESET><YELLOW>!<RESET><GREEN> 3:  b9cb956<RESET><YELLOW> s/11/B/<RESET>
+	:<RED>4:  d966c5c <RESET><YELLOW>!<RESET><GREEN> 4:  8add5f1<RESET><YELLOW> s/12/B/<RESET>
+	EOF
+	git range-diff changed...changed-message --color --dual-color --no-patch >actual.raw &&
+	test_decode_color >actual <actual.raw &&
+	test_cmp expect actual
+'
+
 for prev in topic master..topic
 do
 	test_expect_success "format-patch --range-diff=$prev" '