[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: |
Tue, 21 Feb 2012 21:57:54 +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:40:26PM +0100, David Kastrup wrote:
>> I just bungled staging with bad Texinfo in a regtest and saw that you
>> merged into it right after that, presumably because of a release. I can
>> either replace the merge (it will no longer have the same commit id) or
>> throw it out altogether.
>
> 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.
> I don't mind which option you do. The end result is that we
> should have something tagged for the 2.15.30 release (check git
> tags for the actual string), but it doens't actually matter if
> that tag is accurate or not, provided it's in the right area.
You mean 2.15.31-1 ?
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.
"Nothing can go wrong" TM.
--
David Kastrup