----- Original Message -----
From: "David Kastrup" <d...@gnu.org>
To: "Phil Holmes" <m...@philholmes.net>
Cc: "James Lowe" <p...@gnu.org>; <lilypond-devel@gnu.org>
Sent: Tuesday, May 26, 2015 12:43 PM
Subject: Re: PDF is broken for @notation{} encoding
"Phil Holmes" <m...@philholmes.net> writes:
----- Original Message -----
From: "David Kastrup" <d...@gnu.org>
To: "Phil Holmes" <m...@philholmes.net>
Cc: "James Lowe" <p...@gnu.org>; <lilypond-devel@gnu.org>
Sent: Tuesday, May 26, 2015 11:57 AM
Subject: Re: PDF is broken for @notation{} encoding
Huh. Git bisect would have heeded the _topological_ order and would
have made it more likely you'd have found the correct commit. There is
a git bisect command for reporting an untestable commit, namely "git
bisect skip".
So my best guess is that the change I identified is the culprit here and
that your homegrown bisection did not produce the right commit.
As you can see, the commit you identified is _chronologically_ just
above a commit in the other branch, but both branches have a long
separate history of commits by which they differ previous to that.
--
David Kastrup
Thanks. I'd almost reached that conclusion based on my own look at
git log --graph. I'm starting a "proper" bisect now, rebuilding the
binaries and docs from scratch for each step. Should give the
processor a decent work-out. Catch you in a few hours...
Let's cut this short. Test this patch first. If it fixes the problem,
the bisection is pointless.
That fixes it. Can you push the patch to staging?
--
Phil Holmes
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
