Re: [PATCH v2 3/4] pack-objects.c: do stdin parsing via revision.c's API

From: Jonathan Tan <jonathantanmy@google.com>
Date: Jun 18, 2021, 18:57 UTC
Message-ID: <20210618185728.779629-1-jonathantanmy@google.com>
In-Reply-To: <patch-3.4-d433d7b24a-20210617T105537Z-avarab@gmail.com>

> Change the fgets(..., stdin) parsing in pack-objects.c to use a
> now-extended version of the rev_info stdin parsing API.

This leads me to think that the stdin parsing API is already present, but it turns out that it still needs to be extended. Maybe rewrite this as "extend the rev_info stdin parsing API to support <whatever we need to support>, and change the <...> in pack-objects.c to use it".

Show 25 quoted lines

> @@ -136,6 +149,28 @@ struct rev_info {
>  	 */
>  	int consumed_stdin_per_option;
>  
> +	/*
> +	 * When reading from stdin (see "stdin_handling" above) define
> +	 * a handle_stdin_line function to consume the lines.
> +	 *
> +	 * - Return REV_INFO_STDIN_LINE_PROCESS to continue
> +	 *   revision.c's normal processing of the line (after
> +	 *   possibly munging the provided strbuf).
> +	 *
> +	 * - Return REV_INFO_STDIN_LINE_BREAK to process no further
> +	 *   lines, or anything further from the current line (just
> +	 *   like REV_INFO_STDIN_LINE_CONTINUE).
> +	 *
> +	 * - Return REV_INFO_STDIN_LINE_CONTINUE to indicate that the
> +	 *   line is fully processed, moving onto the next line (if
> +	 *   any)
> +	 *
> +	 * Use the "stdin_line_priv" to optionally pass your own data
> +	 * around.
> +	 */
> +	rev_info_stdin_line_func handle_stdin_line;
> +	void *stdin_line_priv;

I assume that all 3 of these are needed now to minimize the diff (which is fine), but maybe comment on which of these are intended to stay and which are only temporary. In particular, (once things are stabilized) when would a caller need BREAK?

Also mention what happens if handle_stdin_line is not given (I presume that it would just be like a no-op function that returns PROCESS every time).

Looking at the bigger picture, though, and looking at the next patch, this looks like a confusing API especially with the presence of "--not". (In the next patch, you had to introduce a flags field, and the callback has to remember to always handle "--not" and to toggle the flag.) Perhaps the "--not" problem can be solved by making it revision.c's concern and having the callback take a boolean parameter indicating whether "--not" is active or not.