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

Am 17.05.2016 um 21:45 schrieb Jeff King:

On Tue, May 17, 2016 at 09:07:33PM +0200, Johannes Sixt wrote:

quoted

Am 15.05.2016 um 15:05 schrieb Noam Postavsky:

quoted

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