Nick Dokos <nicholas.do...@hp.com> wrote:
> Thomas S. Dye <t...@tsdye.com> wrote:
>
> > ...
> > I did hit on a revision that was neither good nor bad:
> >
> > commit 8562273b272024a630a582b0e1b94c481d8abeec
> > Author: Eric Schulte <schulte.e...@gmail.com>
> > Date: Sat Oct 16 13:21:47 2010 -0600
> >
> > ob-ref: don't forget arguments to referenced code blocks
> >
> > * lisp/ob-ref.el (org-babel-ref-resolve): bringing the referent
> > arguments back to their params before evaluation
> >
> > This one puts these lines in *Messages* when I export to LaTeX
> >
> > executing Org code block...
> > if: Symbol's value as variable is void: result-type
> >
>
> Yeah, that was the error that stopped me cold as well, although I hit it
In case it wasn't clear, that was a couple of days ago on a different
bisection, while chasing another problem.
> on a different commit (I think) - there must be a way to get around the
> problem but it certainly makes things more difficult. I imagine the way
> to go is to find a commit before this error was introduced and a commit
> after it was fixed and try those with your problem: it might allow you
> to bypass the problematic range (in which case, you might be able to
> continue bisecting all the way to the end), or it might limit the bad
> commit to this range - the latter is still valuable to know but
> certainly not as definitive as "this is the bad commit". And in any
> case, all of this would fall into the "advanced" appendix in the git
> bisection book.
>
> Sorry it didn't pan out but I hope that you had fun digging,
>
In this instance, I actually bisected it down to the bad commit that
Jambunathan K. identified (and Carsten reverted). I guess I was lucky
in the sense that I pulled a couple of days ago, so HEAD was 851
commits ahead of 7.01h and the bisection proceeded as follows:
release_7.01h-851-gfd9e933 - bad
release_7.01h - good
release_7.01h-425-gfea9072 - good
release_7.01h-638-gd9e4469 - good
release_7.01h-744-g3d2aec3 - bad <<<<<<
release_7.01h-691-g6b9782d - good
release_7.01h-717-gc9bb51e - bad
release_7.01h-704-g935c310 - good
release_7.01h-710-gc9b0176 - good
release_7.01h-713-g8820a25 - good
release_7.01h-715-gf5918bd - bad
release_7.01h-714-gdf5894c - good
and it identified release_7.01h-715-gf5918bd as the first bad
commit. From the previous investigation, I know that the result-type
error that you ran into, was introduced after commit 750 and resolved
before commit 800 (using release_7.01h as the origin), so once I got to
the <<<< point above, I was safe: I couldn't possibly end up in the
problematic range. OTOH, if you start from say 810, the sequence would
be 405, 608, 709, 759 (or so) and you end up in the problematic range,
which is probably what happened to you.
BTW, I got the bisection sequence (after the fact) with
git bisect log
and then translated the (40-hex digit SHA1 form) commits to the more
readable form above using
git describe <commit>
This is all 20/20 hindsight of course, but I hope interesting
enough as a curiosity.
Nick
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
