On Tue, May 17, 2016 at 3:55 PM, Jeff King <peff@xxxxxxxx> wrote: >> (It's actually the first one which triggers). I'm not familiar enough >> with the code to know whether the col_num computation is bogus, or >> whether we needed to earlier increase the size of the "new_columns" >> field. > > And unsurprisingly, reverting 339c17bc7690b5436ac61c996cede3d52c85b50d > seems to fix this (author cc'd). It's the extra "commit_index" addition > that causes the problem. But I'm still not sure what the correct > solution is. Looking at the coloured output, for some octopus merges where the first parent edge immediately merges into the next column to the left, col_num should be decremented by 1 (otherwise the colour of the "-." doesn't match the rest of that edge). | | *-. | | |\ \ | |/ / / For the other case where the first parent edge stays straight, the current col_num computation is correct. | *-. | |\ \ | | | * I'm not sure how to distinguish these cases in the code though. Is it enough to just compare against graph->num_new_columns? -- 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
