From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Lidong Yan via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Lidong Yan <502024330056@smail.nju.edu.cn>,
Lidong Yan <yldhome2d2@gmail.com>
Subject: Re: [PATCH] diff: stop output garbled message in dry run mode
Date: Fri, 17 Oct 2025 13:17:58 -0700 [thread overview]
Message-ID: <xmqqa51pz3ih.fsf@gitster.g> (raw)
In-Reply-To: <4ff55fc5-7880-b8bf-257f-3186552e9c36@gmx.de> (Johannes Schindelin's message of "Fri, 17 Oct 2025 14:07:50 +0200 (CEST)")
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I do see a still-unguarded `fprintf(o->file, ...)` call in
> `run_diff_cmd()`, but as far as I can see, this call is not in any code
> path where `dry_run` is set.
Among the callers of run_diff_cmd(), only the caller that wants to
report "this path is unmerged" passes NULL diff_filespec pointers in
parameters one and two, in which case run_diff_cmd() would give that
message. So if you have an unmerged filepair in queued_diff, this
callchain
diff_flush()
loop over diff_queued_diff
-> diff_flush_patch_quietly()
fiddle with dry_run bit
-> diff_flush_patch()
-> run_diff()
-> run_diff_cmd() with one&two set to NULL
may hit the fprintf into o->file.
So you are right to worry about that fprintf(). If I make a
whitespace-only change to one file, and then make another path
unmerged, here is what I would see:
$ rungit v2.48.0 diff --raw
:100644 100644 b82c4963e7 0000000000 M cache-tree.h
:000000 100644 0000000000 0000000000 U t/lib-gpg.sh
This is version before that dry-run thing. It operated under the
old rule to show "--raw" to report object differences, hence
ignoring "-w".
$ rungit v2.48.0 diff --raw -w
:100644 100644 b82c4963e7 0000000000 M cache-tree.h
:000000 100644 0000000000 0000000000 U t/lib-gpg.sh
With a version with the dry_run thing, here is what we see:
$ git diff --raw -w
* Unmerged path t/lib-gpg.sh
:000000 100644 0000000000 0000000000 U t/lib-gpg.sh
As dry_run thing intended, the entry on the whitespace-only path is
gone from the output, but the fprintf(o->file) you noticed comes out,
which is not what we want to see. Of course, if we omit -w to avoid
triggering the dry-run thing, we won't see it.
$ git diff --raw
:100644 100644 b82c4963e7 0000000000 M cache-tree.h
:000000 100644 0000000000 0000000000 U t/lib-gpg.sh
As a regression-fix change, I'd feel safer with Peff's version.
Thanks.
next prev parent reply other threads:[~2025-10-17 20:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 3:17 [PATCH] diff: stop output garbled message in dry run mode Lidong Yan via GitGitGadget
2025-10-17 12:07 ` Johannes Schindelin
2025-10-17 19:15 ` Junio C Hamano
2025-10-17 20:19 ` Junio C Hamano
2025-10-17 20:17 ` Junio C Hamano [this message]
2025-10-17 16:17 ` Junio C Hamano
2025-10-18 1:11 ` Lidong Yan
2025-10-18 5:02 ` Junio C Hamano
2025-10-18 9:47 ` Jeff King
2025-10-18 9:50 ` Lidong Yan
2025-10-18 9:56 ` Jeff King
2025-10-18 15:44 ` Junio C Hamano
2025-10-19 14:31 ` Lidong Yan
2025-10-19 15:33 ` Junio C Hamano
2025-10-18 9:48 ` [PATCH v2] " Lidong Yan
2025-10-19 16:20 ` [PATCH v3] " Lidong Yan
2025-10-19 16:30 ` [PATCH v4] " Lidong Yan
2025-10-22 19:53 ` Junio C Hamano
2025-10-22 21:33 ` Junio C Hamano
2025-10-23 0:27 ` Lidong Yan
2025-10-23 12:30 ` Jeff King
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa51pz3ih.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=502024330056@smail.nju.edu.cn \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=yldhome2d2@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.