git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Johannes Sixt <j6t@kdbg.org>
Date
May 17, 2016, 20:02 UTC
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:
Show 23 quoted lines
> 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
Previous: Noam PostavskyNext: Jeff King
Message 21 of 22 in “[BUG] A part of an edge from an octopus merge gets colored, even with --color=never”
  1. Noam PostavskyMay 15, 2016
  2. Johannes SixtMay 17, 2016
  3. Jeff KingMay 17, 2016
  4. Jeff KingMay 17, 2016
  5. Jeff KingMay 17, 2016
  6. Noam PostavskyMay 20, 2016
  7. Noam PostavskyJun 23, 2018
  8. Jeff KingJun 25, 2018
  9. Noam PostavskyJun 30, 2018
  10. Noam PostavskyAug 6, 2018
  11. Jeff KingAug 6, 2018
  12. Jeff KingAug 6, 2018
  13. Noam PostavskySep 2, 2018
  14. Jeff KingSep 8, 2018
  15. Noam PostavskySep 25, 2018
  16. Noam PostavskyOct 3, 2018
  17. Jeff KingOct 3, 2018
  18. Noam PostavskyOct 3, 2018
  19. Jeff KingOct 9, 2018
  20. Noam PostavskyOct 10, 2018
  21. Johannes SixtMay 17, 2016
  22. Jeff KingMay 17, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.