From: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org> To: Junio C Hamano <email@example.com> Cc: firstname.lastname@example.org, "René Scharfe" <email@example.com>, "Michał Kępień" <firstname.lastname@example.org> Subject: Re: [PATCH] diff: fix a segfault in >2 tree -I<regex> and --output=<file> Date: Tue, 24 May 2022 22:17:24 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Tue, May 24 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <email@example.com> 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). 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). 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).
next prev parent reply other threads:[~2022-05-24 20:30 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 [this message] 2022-06-18 11:12 ` René Scharfe 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] diff: fix a segfault in >2 tree -I<regex> and --output=<file>' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git 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).