Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never
- From
Noam Postavsky <npostavs@users.sourceforge.net>
- Date
- May 20, 2016, 22:12 UTC
- Message-ID
- <CAM-tV-9gAGBLsEh3=aa-bHT2DmJb=dfahq+kUW+0GLoc7eFq0w@mail.gmail.com>
- In-Reply-To
- <20160517195541.GC11289@sigill.intra.peff.net>
On Tue, May 17, 2016 at 3:55 PM, Jeff King <peff@peff.net> wrote:
Show 9 quoted lines
>> (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?