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

2013-02-11 Thread John Keeping
On Mon, Feb 11, 2013 at 08:42:21AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: Perhaps it's best to leave the patch as it originally was to guarantee that we can't get stuck in graph_show_commit(), even when it's called at an unexpected time, but I see you've

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

2013-02-11 Thread Junio C Hamano
John Keeping j...@keeping.me.uk writes: On Mon, Feb 11, 2013 at 08:42:21AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: Perhaps it's best to leave the patch as it originally was to guarantee that we can't get stuck in graph_show_commit(), even when it's called at

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

2013-02-10 Thread John Keeping
--- On Sat, Feb 09, 2013 at 03:39:33PM -0800, Junio C Hamano wrote: * jk/diff-graph-cleanup (2013-02-07) 6 commits - combine-diff.c: teach combined diffs about line prefix - diff.c: use diff_line_prefix() where applicable - diff: add diff_line_prefix function - diff.c: make constant

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

2013-02-10 Thread John Keeping
On Sun, Feb 10, 2013 at 11:30:39AM -0800, Junio C Hamano wrote: John Keeping j...@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

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

2013-02-10 Thread Junio C Hamano
John Keeping j...@keeping.me.uk writes: On Sun, Feb 10, 2013 at 11:30:39AM -0800, Junio C Hamano wrote: ... 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