Re: Assertion in git log graphing [regression in v2.25]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 07, 2020 at 08:25:59AM -0500, Derrick Stolee wrote:

> On 1/7/2020 6:48 AM, Jeff King wrote:
> > The assertion itself is quite old, so I wondered if it was even still
> > relevant. Removing it does produce a reasonable-looking graph:
> 
> As I'm digging into this case, and finding when the assertion is hit,
> I see that the issue is in the line further below your coloring issue:

Oh, you're right. I totally missed that.

So perhaps we have two bugs, or perhaps they have the same root cause.

> >   | | | | * dd068b4 Merge commit '8f076d8' into HEAD
> >   | |_|_|/| 
> >   |/| | |/  
> >   | | |/|   
> >   | |/| |   
> >   | * | | 8f076d8 5
> 
> What is output is actually this, above. But the logic that includes the
> assert is checking where the underscores end, and the shown underscores
> actually pass the check. The issue is that it seems like it really wants
> to show this:
> 
> >   | | | | * dd068b4 Merge commit '8f076d8' into HEAD
> >   | |_|_|/| 
> >   |/| |_|/  
> >   | |/| |   
> >   | * | | 8f076d8 5
> 
> Note that I dropped a line and compressed a slash into an underscore. It's
> on that line that this condition is being hit.

Hrm. I could see either being acceptable, but I do think the second one
is a bit easier to read. I'm not sure which was intended for this case.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux