On Wed, Mar 23 2022, Raphael Bauer wrote: > Hello, > > I am not familiar with using mailing list for bug tracking. I already > reported this bug, but got no answer, so I wanted to mention it again. There was my answer at https://lore.kernel.org/git/220222.865yp7aj6z.gmgdl@xxxxxxxxxxxxxxxxxxx/ and your reply at https://lore.kernel.org/git/6f0d1c12-4cf8-bbdd-96d4-eae99317e2e4@xxxxxxx/; Perhaps not the answer you wanted, but not "no answer"... > * What did you do before the bug happened? (Steps to reproduce your issue) > git log --pretty=format:'%h%Cred%+d test' --graph > > This also happens with a PAGER=cat environment, just to preclude this > is related to the pager. This example also renders differently under PAGER=cat for me. I.e. it's the pager that's resetting the colors, but maybe I'm not understanding the subtlety here... > * What did you expect to happen? (Expected behavior) > A graph listing of commit hashes and, if ref names for this commit > exist, a second line. > This line should be colored in red and contain the ref names as well > as the string 'test'. > In the case of no refs, the string 'test' should appear in line with > the commit hash, also in red. > > * What happened instead? (Actual behavior) > In case of ref names / a second line, the color is missing completely. > The colors work correctly for the single line case (when no ref names > are available). > > * What's different between what you expected and what actually happened? > The %+d placeholder inserts newlines if the string is non-empty, but > in doing so, resets any coloring information. > This is demonstrated by the string 'test' which should always show in > red, but does so only if %+d is not expanded. > This makes it currently impossible to color anything with the %+ > placeholder. At least for me a screenshot & a link to a repo you expect to run this on would really help, since the output is very different depending on branch topology, ref names etc.
