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

> This whole version looks good to me. "git am" is supposed to understand > attachments, but it seems to want to apply our whole conversation as the > commit message. > > You may want to repost one more time with this subject in the email > subject line to fix that and to get the maintainer's

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

On Wed, Oct 03, 2018 at 06:32:06PM -0400, Noam Postavsky wrote: > > which is admittedly pretty horrible, too, but at least resembles a > > graph. I dunno. > > Yeah, but it's lossy, so it doesn't seem usable for the test. Maybe > doubling up some characters? > > ** left > R| **B-B-M-M.

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

On Wed, 3 Oct 2018 at 00:24, Jeff King wrote: > Yeah, I really like your explanations/diagrams in the comments. It makes > the logic very clear. Ok good, I did have the feeling that the logic became actually clearer to me after I wrestled with the test code, so I think this means I didn't just

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

On Mon, Sep 24, 2018 at 08:27:47PM -0400, Noam Postavsky wrote: > > So I think this is doing the right thing. I'm not sure if there's a > > better way to explain "dashless" or not. > > I've updated the comments and renamed a few variables, see if that helps. Yeah, I really like your

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

On Mon, 24 Sep 2018 at 20:27, Noam Postavsky wrote: > > On Sat, 8 Sep 2018 at 12:13, Jeff King wrote: > > > Great (and sorry for the delayed response). > > No problem, I know it's not the most urgent bug ever :) Ping. :) > I managed to recast my script into the framework of the > other tests

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

On Sat, 8 Sep 2018 at 12:13, Jeff King wrote: > Great (and sorry for the delayed response). No problem, I know it's not the most urgent bug ever :) > So I think this is doing the right thing. I'm not sure if there's a > better way to explain "dashless" or not. I've updated the comments and

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

On Sat, Sep 01, 2018 at 08:34:41PM -0400, Noam Postavsky wrote: > On 6 August 2018 at 17:26, Jeff King wrote: > > > I suspect it still has a bug, which is that it is handling this > > first-parent-goes-left case, but probably gets the straight-parent case > > wrong. But at least in this form, I

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

On 6 August 2018 at 17:26, Jeff King wrote: > I suspect it still has a bug, which is that it is handling this > first-parent-goes-left case, but probably gets the straight-parent case > wrong. But at least in this form, I think it is obvious to see where > that bug is (the "three" in the comment

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

On Mon, Aug 06, 2018 at 02:34:45PM -0400, Noam Postavsky wrote: > On 30 June 2018 at 08:47, Noam Postavsky > wrote: > > > I'm still having trouble getting a big picture understanding of how > > the graph struct relates the what gets drawn on screen, but through > > some poking around with the

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

On Sat, Jun 30, 2018 at 08:47:16AM -0400, Noam Postavsky wrote: > I'm still having trouble getting a big picture understanding of how > the graph struct relates the what gets drawn on screen, but through > some poking around with the debugger + trial & error, I've arrived at > a new patch which

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

On 30 June 2018 at 08:47, Noam Postavsky wrote: > I'm still having trouble getting a big picture understanding of how > the graph struct relates the what gets drawn on screen, but through > some poking around with the debugger + trial & error, I've arrived at > a new patch which seems to work.

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

On 25 June 2018 at 12:23, Jeff King wrote: > These diagrams confused me for a minute, because I see two differences: > > 1. The first one has an extra apparently unrelated parallel branch on > the far left. > > 2. The first has the first-parent of the "*" merge commit immediately >

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

On Sat, Jun 23, 2018 at 05:45:19PM -0400, Noam Postavsky wrote: > On 20 May 2016 at 18:12, Noam Postavsky > wrote: My, this is a blast from the past. :) > Subject: [PATCH v1] log: Fix coloring of certain octupus merge shapes > > For octopus merges where the first parent edge immediately

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

Archive link to previous discussion: https://marc.info/?l=git=146331754420554=2 On 20 May 2016 at 18:12, Noam Postavsky wrote: > Looking at the coloured output, for some octopus merges where the > first parent edge immediately merges into the next column to the left, > col_num should be

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

On Tue, May 17, 2016 at 3:55 PM, Jeff King wrote: >> (It's actually the first one which triggers). I'm not familiar enough >> with the code to know whether the col_num computation is bogus, or >> whether we needed to earlier increase the size of the "new_columns" >> field. > > And

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

On Tue, May 17, 2016 at 10:02:22PM +0200, Johannes Sixt wrote: > > 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. Heh, I meant that Noam's test worked out of the box. I also

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: 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

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

On Tue, May 17, 2016 at 03:51:37PM -0400, Jeff King wrote: > On Tue, May 17, 2016 at 03:45:34PM -0400, Jeff King wrote: > > > Note that we set up f90, fa0, and fb0, but then pass fc0 into > > strbuf_write_column (and it has bogus color values). It looks like we're > > reading one past the end of

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

On Tue, May 17, 2016 at 03:45:34PM -0400, Jeff King wrote: > Note that we set up f90, fa0, and fb0, but then pass fc0 into > strbuf_write_column (and it has bogus color values). It looks like we're > reading one past the end of our array, but I haven't figured out where > or why. Looking at the

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

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

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

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

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

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