list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "René Scharfe" <>
To: "Ævar Arnfjörð Bjarmason" <>,
	"Junio C Hamano" <>
Cc:, "Michał Kępień" <>
Subject: Re: [PATCH] diff: fix a segfault in >2 tree -I<regex> and --output=<file>
Date: Sat, 18 Jun 2022 13:12:13 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Am 24.05.22 um 22:17 schrieb Ævar Arnfjörð Bjarmason:
> On Tue, May 24 2022, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason <> writes:
>>> I.e. the "right" thing to do in this case would require a much more
>>> involved fix. We've somehow ended up not supporting --output=<file>, -I
>>> and probably many other options in the combined-diff mode, which both in
>>> testing and in this part of the implementation seems to have become an
>>> afterthought.
>> OK, a hopefully final question.
>> How much less involved is it to add a new code (without doing
>> anything in this patch)
> ...yeah, I think for this one it makes sense to narrowly focus on the
> segfault...
>> to detect and die on the combination of
>> combined-diff with these two options, so that we can document the
>> fact that we do not support them?  It would give us much better way
>> forward than leaving the command silently ignore and give result
>> that is not in line with what was asked, wouldn't it?  That way, the
>> much more involved "fix" will turn into a change to add a missing
>> feature.
> I think not much, it's rather trivial for the case where we invoke "git
> diff", I.e. just adding something to the "builtin_diff_combined()"
> branch in builtin/diff.c to detect these two cases specifically.
> I haven't looked in any depth into how we might reach code in
> combine-diff.c through other means, and if any of it can set these two
> indirectly somewhere else (i.e. other things that take diff options).

So let's add those checks there.

> I also wonder if I'm just wrong in my assessment that it's a Bad Thing
> that we take some of these without ever doing anything with them in some
> modes, e.g.:
> 	git log --oneline -I foo
> This will never do anything with that "-I foo" by definition, but would
> as soon as you add -p, should we error without -p (or other diff-showing
> options).

Which definition?  The documentation says:

       -I<regex>, --ignore-matching-lines=<regex>
           Ignore changes whose all lines match <regex>. This option may be specified more than once.

That sounds to me like it would affect history simplification, and thus
git log --oneline.  (Which seems expensive, but that's a different
concern.)  So based on that I'd expect at least a warning if -I is

> The same goes for range-diff, format-patch, --remerge-diff and any
> number of other things where we take the full set of options, but only
> do something with a limited subset of them.
> It is helpful in some cases if we were more anal about it, e.g. when I
> was wondering why -I didn't do anything with the combined diff, but also
> handy for scripting and one-liners if you can tweak the command-line
> back & forth without it being so strict.
> So I don't know. Maybe I'm just trying to talk myself out of pulling on
> that (bound to be long) thread, but I'm coming more around to this just
> being a non-issue beyond the narrow and needed fix for diff_free() in
> particular.
> I.e. the more general approach of chasing down options that don't do
> anything for a given "diff mode". We might still want to error on some
> particular ones, such as -I with the combined diff (but not with
> --oneline, or whatever).

Supporting all combinations would be ideal.  Reporting unsupported
combinations would be the next best thing.  I wonder if we passed the
point of having so many options for e.g. git log that assessing all
of their pairings has become impractical, though. :-/


  reply	other threads:[~2022-06-18 11:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-14  9:32 Bug: combined diff with --ignore-matching-lines René Scharfe
2022-05-23 18:31 ` [PATCH] diff: fix a segfault in >2 tree -I<regex> and --output=<file> Ævar Arnfjörð Bjarmason
2022-05-23 20:08   ` Junio C Hamano
2022-05-24 11:38     ` Ævar Arnfjörð Bjarmason
2022-05-24 19:38       ` Junio C Hamano
2022-05-24 20:17         ` Ævar Arnfjörð Bjarmason
2022-06-18 11:12           ` René Scharfe [this message]
2022-06-18 11:12           ` [PATCH 1/2] combine-diff: abort if --ignore-matching-lines is given René Scharfe
2022-06-21 15:35             ` Junio C Hamano
2022-06-21 15:58               ` René Scharfe
2022-06-21 16:55                 ` Junio C Hamano
2022-06-18 11:12           ` [PATCH 2/2] combine-diff: abort if --output " René Scharfe

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 \ \ \ \ \ \ \

* 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 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).