[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LSR updates: was: polychords: a working solution
From: |
David Kastrup |
Subject: |
Re: LSR updates: was: polychords: a working solution |
Date: |
Wed, 22 Feb 2012 09:24:38 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Graham Percival <address@hidden> writes:
> On Tue, Feb 21, 2012 at 09:57:54PM +0100, David Kastrup wrote:
>> Graham Percival <address@hidden> writes:
>> > oh, I see. That was actually a clean-up from 2.15.30, because the
>> > tag got lost because release/unstable didn't merge into master
>> > properly. (why? no clue; I just followed the instructions in the
>> > CG -- but this isn't the first time those instructions have
>> > resulted in not having the right commit in master).
>>
>> Hm? release/2.15.30-1 is there alright.
>>
>> You mean 2.15.31-1 ?
>
> No, I mean release/2.15.30-1. It's not in the history for master
> -- that is to say, if I look at the history in gitk, I can scroll
> down and see release/2.15.29-1, release/2.15.28-1, etc. But not
> release/2.15.30-1.
Ah, ok. A pure graph-changing merge without content. Pushed it.
>> I've just cleared staging of your merge commit and am currently
>> rerunning the staging patchy. It _is_ rather strange that the @q macro
>> is defined in the documentation in general, but not for the snippet
>> headers.
>
> hmm, I see @include macros.itexi in Documentation/snippets.tely,
> which should handle it.
Well, it didn't. Don't ask me why or in what context.
--
David Kastrup