From: Jeff King Date: Wed, 22 Oct 2025 09:14:33 GMT Subject: Re: Regression in `git diff --quiet HEAD` when a new file is staged Message-ID: <20251022091433.GC853931@coredump.intra.peff.net> In-Reply-To: On Wed, Oct 22, 2025 at 12:46:55PM +0800, Lidong Yan wrote: > Junio C Hamano writes: > > > > /* return 1 if any change is found; otherwise, return 0 */ > > static int diff_flush_patch_quietly(struct diff_filepair *p, struct diff_options *o) > > { > > @@ -6179,6 +6181,15 @@ static int diff_flush_patch_quietly(struct diff_filepair *p, struct diff_options > > int saved_found_changes = o->found_changes; > > int ret; > > > > + /* > > + * run diff_flush_patch for the exit status. setting > > + * options->file to /dev/null should be safe, because we > > + * aren't supposed to produce any output anyway. > > + */ > > + diff_free_file(o); > > + o->file = xfopen("/dev/null", "w"); > > + o->close_file = 1; > > + o->color_moved = 0; > > o->dry_run = 1; > > o->found_changes = 0; > > diff_flush_patch(p, o); > > > > This would make everything going to "/dev/null" after the flush_quietly() call. > I think we need to restore o->file. We probably also need to restore o->color_moved, too. In the long run (and this is the kind of cleanup I was hoping you'd work on for 'master'), we probably could drop that line entirely and just skip running the moved-line detection when dry_run is set. Assuming it even runs at all. From a quick look at the code, it looks like we only do color-moved handling via diff_flush_patch_all_file_pairs(), so it wouldn't trigger at all for the cases that do individual calls to diff_flush_patch_quietly()? -Peff