git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Orgad Shaneh via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Orgad Shaneh <orgads@gmail.com>
Subject: Re: [PATCH] clean: flush after each line
Date: Wed, 01 Feb 2023 09:45:28 -0800	[thread overview]
Message-ID: <xmqqedr91dqf.fsf@gitster.g> (raw)
In-Reply-To: <pull.1447.git.git.1675246158282.gitgitgadget@gmail.com> (Orgad Shaneh via GitGitGadget's message of "Wed, 01 Feb 2023 10:09:18 +0000")

"Orgad Shaneh via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Orgad Shaneh <orgads@gmail.com>
>
> Some platforms don't automatically flush after \n, and this causes delay
> of the output, and also sometimes incomplete file names appear until the
> next chunk is flushed.
>
> Reported here: https://github.com/git-for-windows/git/issues/3706
>
> Signed-off-by: Orgad Shaneh <orgads@gmail.com>
> ---
>     clean: flush after each line

We do not flush after every line when producing output from "git
diff", "git status".  I do not want to see "git clean" special
cased, as such a solution will not scale.

> diff --git a/builtin/clean.c b/builtin/clean.c
> index b2701a28158..f3de8170f9a 100644
> --- a/builtin/clean.c
> +++ b/builtin/clean.c
> @@ -270,8 +270,10 @@ static int remove_dirs(struct strbuf *path, const char *prefix, int force_flag,
>  
>  	if (!*dir_gone && !quiet) {
>  		int i;
> -		for (i = 0; i < dels.nr; i++)
> +		for (i = 0; i < dels.nr; i++) {
>  			printf(dry_run ?  _(msg_would_remove) : _(msg_remove), dels.items[i].string);
> +			fflush(stdout);
> +		}

If the standard output is connected to an interactive terminal, this
might make sense (but then that equally applies to "git status",
"git diff" and all other commands), but shouldn't the stdout follow
the simple "Output streams that refer to terminal devices are always
line buffered by default" rule?

I think this should be fixed at the platform level, either by
talking to the platform maintainers.  An acceptable workaround may
be to have an #ifdef'ed hack early in our start-up code, e.g.

	void sanitize_stdfds(void)
	{
		int fd = ...;
		if (fd > 2)
			close(fd);
	#ifdef BUGGY_STDOUT_FULLY_BUFFERED
		if (isatty(1))
			setlinebuf(stdout);
	#endif
	}

somewhere that is reached early from common-main.c::main().

That way, we do not have to carry a special-case in builtin/clean.c
and watch out for other commands that produce multiple lines of
output start needing a workaround on platforms with such a buffering
behaviour.

> @@ -544,6 +546,7 @@ static int parse_choice(struct menu_stuff *menu_stuff,
>  			clean_print_color(CLEAN_COLOR_ERROR);
>  			printf(_("Huh (%s)?\n"), (*ptr)->buf);
>  			clean_print_color(CLEAN_COLOR_RESET);
> +			fflush(stdout);
>  			continue;

This is clearly interactive codepath, and I do not think we mind an
extra fflush().  But it would be redundant if we fix the stdio on
such a platform.

>  		}
>  
>
> base-commit: 2fc9e9ca3c7505bc60069f11e7ef09b1aeeee473

      reply	other threads:[~2023-02-01 17:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 10:09 [PATCH] clean: flush after each line Orgad Shaneh via GitGitGadget
2023-02-01 17:45 ` Junio C Hamano [this message]

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 \
    --in-reply-to=xmqqedr91dqf.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=orgads@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.
Code repositories for project(s) associated with this public 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).