Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

[Johannes Sixt <j6t@kdbg.org>]

Am 17.05.2016 um 21:45 schrieb Jeff King:
> On Tue, May 17, 2016 at 09:07:33PM +0200, Johannes Sixt wrote:
>
>> Am 15.05.2016 um 15:05 schrieb Noam Postavsky:
>>> With a certain topology involving an octopus merge, git log --graph
>>> --oneline --all --color=never produces output which includes some ANSI
>>> escape code coloring. Attached is a script to reproduce the problem
>>> (creates a git repository in subdir log-format-test), along with
>>> sample graph and valgrind output (indicates some unitialialized memory
>>> access).
>>>
>>> I've observed the problem with Windows git versions 2.7.0, 2.5.3.
>>> I've NOT observed it with 1.9.5,
>>>
>>> On GNU/Linux the symptom only appears when running with valgrind, I
>>> tried versions
>>> 2.8.0, and 2.8.2.402.gedec370 (the last is where the valgrind output comes from)
>>>
>>
>> Sorry, I can't reproduce your observation. I ran the script you provided
>> with HOME=$PWD and a minimal .gitconfig that only sets user.email. But
>> valgrind is happy with both 2.8.0 and v2.8.2-402-gedec370 on my Linux box.
>
> Interesting. It replicates out of the box for me.

"Out of the box" are the magic words. I usually compile with -O0, which 
doesn't trigger the valgrind report.

When I compile with a 3.x based gcc on Windows, I see these warnings:

     CC color.o
color.c: In function 'color_parse_mem':
color.c:203: warning: 'c.value' may be used uninitialized in this function
color.c:203: warning: 'c.blue' may be used uninitialized in this function
color.c:203: warning: 'c.green' may be used uninitialized in this function
color.c:203: warning: 'c.red' may be used uninitialized in this function

(which triggered my curiosity in this bug report). But they seem to be 
unrelated and are most likely false positives.

-- Hannes