emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Re: Internal links in LaTeX export


From: Jambunathan K
Subject: Re: [Orgmode] Re: Internal links in LaTeX export
Date: Fri, 29 Oct 2010 15:47:12 +0530
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (windows-nt)

Nick

I hunted down the bug with heuristics.

Speaking of bisections,

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

Git bisection is wonderful. It is a bit of drag nevertheless - Tag,
Test, Tag, Test Tag, Test .... Ah, finally done (or undecided)

In the case at hand, it is clear that the issue is with either
org-latex.el (or org-exp.el). It is most likely the former because the
bug description is backend-specific.

I wish there was a way to say this:

- "do bisection on the revisions where org-latex.el changed (as opposed
   to revisions where HEAD moved)"

The candidate commits then would have reduced to 30 odd commits rather
than 851 that one had to contend with.

Hypothetically speaking, even this improved bisection would have left me
confused at somepoint because of the churn 'pdflatex & texi2dvi' churn
that pdf export process went through in recent times.

Jambunathan K.

> This is all 20/20 hindsight of course, but I hope interesting
> enough as a curiosity.
>
> Nick



reply via email to

[Prev in Thread] Current Thread [Next in Thread]