John Keeping <john@xxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html