threads / patch / 59172

patchclean: flush after each line

Subject: [PATCH] clean: flush after each line

## tl;dr

2 messages between Feb 1, 2023 and Feb 1, 2023. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

Orgad Shaneh via GitGitGadget· Feb 1, 2023, 10:09 UTC · lore
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
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1447%2Forgads%2Fclean-flush-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1447/orgads/clean-flush-v1
Pull-Request: https://github.com/git/git/pull/1447
 builtin/clean.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
Show changes to builtin/clean.c +4 −1
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);
+		}
 	}
 out:
 	strbuf_release(&realpath);
@@ -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;
 		}
 

base-commit: 2fc9e9ca3c7505bc60069f11e7ef09b1aeeee473
-- 
gitgitgadget
Junio C Hamano· Feb 1, 2023, 17:45 UTC · re: Orgad Shaneh via GitGitGadget · lore

Re: [PATCH] clean: flush after each line

"Orgad Shaneh via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 11 quoted lines
> 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.

Show 13 quoted lines
> 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.

Show 6 quoted lines
> @@ -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

← back to recent threads