From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 10 Feb 2013 19:30:39 GMT
Subject: Re: [PATCH] fixup! graph: output padding for merge subsequent parents
Message-ID: <7vliawt19c.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130210131647.GA2270@serenity.lan>

John Keeping <john@keeping.me.uk> writes:

> Can you squash this into the first commit before you do?
>
> Matthieu is correct that the graph_is_commit_finished() check isn't
> needed in the loop now that we've pulled it out to be checked first -
> the value returned can't change during the loop.  I've left the early
> return out.
>
>  graph.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/graph.c b/graph.c
> index 2a3fc5c..56f970f 100644
> --- a/graph.c
> +++ b/graph.c
> @@ -1237,7 +1237,7 @@ void graph_show_commit(struct git_graph *graph)
>  		shown_commit_line = 1;
>  	}
>  
> -	while (!shown_commit_line && !graph_is_commit_finished(graph)) {
> +	while (!shown_commit_line) {
>  		shown_commit_line = graph_next_line(graph, &msgbuf);
>  		fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
>  		if (!shown_commit_line)

Is it correct to say that this essentially re-does 656197ad3805
(graph.c: infinite loop in git whatchanged --graph -m, 2009-07-25)
in a slightly different way, in that Michał's original fix also
protected against the case where graph->state is flipped to
GRAPH_PADDING by graph_next_line() that returns false, but with your
fixup, the code knows it never happens (i.e. when graph_next_line()
returns false, graph->state is always in the GRAPH_PADDING state),
and the only thing we need to be careful about is when graph->state
is already in the PADDING state upon entry to this function?

Sorry for an overlong single sentence question ;-)

Thanks.