git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] fixup! graph: output padding for merge subsequent parents

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 10, 2013, 19:30 UTC
Message-ID
<7vliawt19c.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20130210131647.GA2270@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
Show 23 quoted lines
> 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.
Previous: John KeepingNext: John Keeping
Message 3 of 11 in “What's cooking in git.git (Feb 2013, #04; Sat, 9)”
  1. Junio C HamanoFeb 9, 2013
  2. fixup! graph: output padding for merge subsequent parentsJohn Keeping, Feb 10, 2013
  3. Junio C HamanoFeb 10, 2013
  4. John KeepingFeb 10, 2013
  5. Junio C HamanoFeb 10, 2013
  6. John KeepingFeb 11, 2013
  7. Junio C HamanoFeb 11, 2013
  8. John KeepingFeb 11, 2013
  9. Junio C HamanoFeb 11, 2013
  10. Matthieu MoyFeb 11, 2013
  11. Junio C HamanoFeb 11, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.