| Message ID | 20181105200650.31177-1-avarab@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | range-diff: add a --no-patch option to show a summary | expand |
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/
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/
Æ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.
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.
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.
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.
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/ >
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/ >>
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/ > >> >
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
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
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
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" '
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(-)