git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: "Xiaoguang WANG" <wxiaoguang@gmail.com>,
	"Taylor Blau" <me@ttaylorr.com>,
	"Torsten Bögershausen" <tboegi@web.de>,
	"Chandra Pratap" <chandrapratap3519@gmail.com>,
	git@vger.kernel.org
Subject: Re: Bug report: Incorrect GIT_FLUSH behavior in 2.43.1 (regression and breaking)
Date: Tue, 13 Feb 2024 09:26:47 -0800	[thread overview]
Message-ID: <xmqqle7o6zs8.fsf@gitster.g> (raw)
In-Reply-To: <c243c260-b346-4b53-b8a2-685389ad344e@gmail.com> (Phillip Wood's message of "Tue, 13 Feb 2024 11:07:58 +0000")

Phillip Wood <phillip.wood123@gmail.com> writes:

> Given we're in a rc-period a minimal fix like this looks appropriate
> (though it is missing some braces according to our coding
> guidelines). The interaction of "skip_stdout_flush" and git_env_bool()
> is unfortunate, It might be clearer if we changed to having
> "force_stdout_flush" instead but that would be a more invasive change.

I admit that I did find the polarity of the existing variable
annoying, and it does make sense to flip it like you did here.

Unfortunately the minimum fix is already in 'next', so let me turn
what you wrote into an update relative to that.  I'll assume your
patch in the discussion is signed-off already?

------- >8 ------------- >8 ------------- >8 -------
From: Phillip Wood <phillip.wood123@gmail.com>
Subject: maybe_flush_or_die(): flip the polarity of an internal variable

We take GIT_FLUSH that tells us if we want to flush (or not) from
the outside, but internally use a variable that tells us to skip (or
not) the flushing operation, which makes the code flow unnecessarily
confusing to read.

With the understanding of the original motivation behind "skip" in
06f59e9f (Don't fflush(stdout) when it's not helpful, 2007-06-29),
we can sympathize with the current naming (we wanted to avoid
useless flushing of stdout by default, with an escape hatch to
always flush), but it is still not a good excuse.

Retire the "skip_stdout_flush" variable and replace it with "flush_stdout"
that tells if we do or do not want to run fflush().

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 write-or-die.c | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git c/write-or-die.c w/write-or-die.c
index 3ecb9e2af5..01a9a51fa2 100644
--- c/write-or-die.c
+++ w/write-or-die.c
@@ -18,23 +18,20 @@
  */
 void maybe_flush_or_die(FILE *f, const char *desc)
 {
-	static int skip_stdout_flush = -1;
-
 	if (f == stdout) {
-		if (skip_stdout_flush < 0) {
-			int flush_setting = git_env_bool("GIT_FLUSH", -1);
+		static int force_flush_stdout = -1;
 
-			if (0 <= flush_setting)
-				skip_stdout_flush = !flush_setting;
-			else {
+		if (force_flush_stdout < 0) {
+			force_flush_stdout = git_env_bool("GIT_FLUSH", -1);
+			if (force_flush_stdout < 0) {
 				struct stat st;
 				if (fstat(fileno(stdout), &st))
-					skip_stdout_flush = 0;
+					force_flush_stdout = 1;
 				else
-					skip_stdout_flush = S_ISREG(st.st_mode);
+					force_flush_stdout = !S_ISREG(st.st_mode);
 			}
 		}
-		if (skip_stdout_flush && !ferror(f))
+		if (!force_flush_stdout && !ferror(f))
 			return;
 	}
 	if (fflush(f)) {

  reply	other threads:[~2024-02-13 17:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12 15:18 Bug report: Incorrect GIT_FLUSH behavior in 2.43.1 (regression and breaking) Xiaoguang WANG
2024-02-12 17:11 ` Junio C Hamano
2024-02-12 17:18   ` Xiaoguang WANG
2024-02-13 11:07   ` Phillip Wood
2024-02-13 17:26     ` Junio C Hamano [this message]
2024-02-13 19:48       ` Junio C Hamano
2024-02-14 10:57         ` Phillip Wood

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=xmqqle7o6zs8.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=chandrapratap3519@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=phillip.wood123@gmail.com \
    --cc=tboegi@web.de \
    --cc=wxiaoguang@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 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 NNTP newsgroup(s).