From: Johannes Sixt Date: Tue, 17 May 2016 20:02:22 GMT Subject: Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never Message-ID: <573B78CE.1080200@kdbg.org> In-Reply-To: <20160517194533.GA11289@sigill.intra.peff.net> 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