Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

2017-01-12 Thread David Nalesnik 
On Wed, Jan 11, 2017 at 10:44 AM, David Nalesnik
 wrote:
> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels  wrote:
>>
>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>
>>
>>> Ok, so I will probably do
>>>
>>> git revert HEAD
>>>
>>> in my staging branch
>>>
>>> and push it to origin/staging.
>>>
>>> ---
>>>
>>> I won't attempt to clear the LSR queue in preparation for my patch
>>> update (as I did) by running makelsr.py again.
>>>
>>> When I update my issue, I'll simply add my snippet to snippets/new,
>>> and leave updating the LSR to the future (when the frenched-score
>>> snippet and my proposed snippet and whatever else appears will be
>>> integrated)
>>
>> Sorry my recipe caused a problem in this case.  Normally clearing
>> the old LSR queue first with makelsr.py would be fine.  But what
>> you suggest is also OK, as long as someone fixes the problem and
>> runs makelsr.py reasonably soon - before the next new snippet is
>> added (I can't run it myself - on my Windows Vista it always tries
>> to change all the \ to / or vice versa.)
>>
>
> I think the only problem is that @{MarkLines} should be replaced with
> @code{MarkLines}.
>
> I'm stuck in the middle of a make doc checking the change.  When I'm
> through that, I'll revert the update.
>
> Then I can push an update of the snippet to staging.  (But I'll save
> the makelsr for later as James says.)

I've made the change and verified that make doc works after makelsr.
Shall I push the fix directly to staging?  (Just the Texinfo change,
not the updates from makelsr).

Thanks,

David

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

2017-01-11 Thread David Nalesnik 
On Wed, Jan 11, 2017 at 1:52 PM, David Kastrup  wrote:
> David Nalesnik  writes:
>
>> On Wed, Jan 11, 2017 at 12:31 PM, David Kastrup  wrote:
>>>
>>> It's nicer to _remove_ the patch from staging instead of adding the
>>> revert on top.  However, that requires more skills.  I can offer to do
>>> this, but you'll still need to remove the patch on your side before
>>> trying to push anything else.
>>>
>>
>> Before this email arrived, I already pushed the revert to staging.
>> Staging hasn't caught up with master yet.  If it's still reasonable to
>> remove the commit and revert, that would be appreciated.  I could do
>> with one fewer blot on the project history in my name!
>
> I've removed commit and revert from staging.  Now you just need to make
> sure that you don't repush them on your next attempt to push something:
> you probably need some invocation of git reset --hard in order to do so.
>

Thank you so much, David!

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

2017-01-11 Thread David Kastrup 
David Nalesnik  writes:

> On Wed, Jan 11, 2017 at 12:31 PM, David Kastrup  wrote:
>>
>> It's nicer to _remove_ the patch from staging instead of adding the
>> revert on top.  However, that requires more skills.  I can offer to do
>> this, but you'll still need to remove the patch on your side before
>> trying to push anything else.
>>
>
> Before this email arrived, I already pushed the revert to staging.
> Staging hasn't caught up with master yet.  If it's still reasonable to
> remove the commit and revert, that would be appreciated.  I could do
> with one fewer blot on the project history in my name!

I've removed commit and revert from staging.  Now you just need to make
sure that you don't repush them on your next attempt to push something:
you probably need some invocation of git reset --hard in order to do so.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

2017-01-11 Thread David Nalesnik 
On Wed, Jan 11, 2017 at 12:31 PM, David Kastrup  wrote:
> David Nalesnik  writes:
>
>> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels  wrote:
>>>
>>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>>
>>>
 Ok, so I will probably do

 git revert HEAD

 in my staging branch

 and push it to origin/staging.

 ---

 I won't attempt to clear the LSR queue in preparation for my patch
 update (as I did) by running makelsr.py again.

 When I update my issue, I'll simply add my snippet to snippets/new,
 and leave updating the LSR to the future (when the frenched-score
 snippet and my proposed snippet and whatever else appears will be
 integrated)
>>>
>>> Sorry my recipe caused a problem in this case.  Normally clearing
>>> the old LSR queue first with makelsr.py would be fine.  But what
>>> you suggest is also OK, as long as someone fixes the problem and
>>> runs makelsr.py reasonably soon - before the next new snippet is
>>> added (I can't run it myself - on my Windows Vista it always tries
>>> to change all the \ to / or vice versa.)
>>>
>>
>> I think the only problem is that @{MarkLines} should be replaced with
>> @code{MarkLines}.
>>
>> I'm stuck in the middle of a make doc checking the change.  When I'm
>> through that, I'll revert the update.
>>
>> Then I can push an update of the snippet to staging.  (But I'll save
>> the makelsr for later as James says.)
>>
>> No problem, it's all a learning experience for me!
>
> It's nicer to _remove_ the patch from staging instead of adding the
> revert on top.  However, that requires more skills.  I can offer to do
> this, but you'll still need to remove the patch on your side before
> trying to push anything else.
>

Before this email arrived, I already pushed the revert to staging.
Staging hasn't caught up with master yet.  If it's still reasonable to
remove the commit and revert, that would be appreciated.  I could do
with one fewer blot on the project history in my name!

Thanks,
David N

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

2017-01-11 Thread David Kastrup 
David Nalesnik  writes:

> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels  wrote:
>>
>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>
>>
>>> Ok, so I will probably do
>>>
>>> git revert HEAD
>>>
>>> in my staging branch
>>>
>>> and push it to origin/staging.
>>>
>>> ---
>>>
>>> I won't attempt to clear the LSR queue in preparation for my patch
>>> update (as I did) by running makelsr.py again.
>>>
>>> When I update my issue, I'll simply add my snippet to snippets/new,
>>> and leave updating the LSR to the future (when the frenched-score
>>> snippet and my proposed snippet and whatever else appears will be
>>> integrated)
>>
>> Sorry my recipe caused a problem in this case.  Normally clearing
>> the old LSR queue first with makelsr.py would be fine.  But what
>> you suggest is also OK, as long as someone fixes the problem and
>> runs makelsr.py reasonably soon - before the next new snippet is
>> added (I can't run it myself - on my Windows Vista it always tries
>> to change all the \ to / or vice versa.)
>>
>
> I think the only problem is that @{MarkLines} should be replaced with
> @code{MarkLines}.
>
> I'm stuck in the middle of a make doc checking the change.  When I'm
> through that, I'll revert the update.
>
> Then I can push an update of the snippet to staging.  (But I'll save
> the makelsr for later as James says.)
>
> No problem, it's all a learning experience for me!

It's nicer to _remove_ the patch from staging instead of adding the
revert on top.  However, that requires more skills.  I can offer to do
this, but you'll still need to remove the patch on your side before
trying to push anything else.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

2017-01-11 Thread David Nalesnik 
On Wed, Jan 11, 2017 at 10:59 AM, James  wrote:
> Hello,
>
>
>
> On 11/01/17 16:44, David Nalesnik wrote:
>>
>> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels 
>> wrote:
>>>
>>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>>
>>>
 Ok, so I will probably do

 git revert HEAD

 in my staging branch

 and push it to origin/staging.

 ---

 I won't attempt to clear the LSR queue in preparation for my patch
 update (as I did) by running makelsr.py again.

 When I update my issue, I'll simply add my snippet to snippets/new,
 and leave updating the LSR to the future (when the frenched-score
 snippet and my proposed snippet and whatever else appears will be
 integrated)
>>>
>>> Sorry my recipe caused a problem in this case.  Normally clearing
>>> the old LSR queue first with makelsr.py would be fine.  But what
>>> you suggest is also OK, as long as someone fixes the problem and
>>> runs makelsr.py reasonably soon - before the next new snippet is
>>> added (I can't run it myself - on my Windows Vista it always tries
>>> to change all the \ to / or vice versa.)
>>>
>> I think the only problem is that @{MarkLines} should be replaced with
>> @code{MarkLines}.
>>
>> I'm stuck in the middle of a make doc checking the change.  When I'm
>> through that, I'll revert the update.
>>
>> Then I can push an update of the snippet to staging.  (But I'll save
>> the makelsr for later as James says.)
>>
>> No problem, it's all a learning experience for me!
>
>
> The staging merge runs every 4 hours - on my own server - so depending on
> when you eventually push to staging again, if you still see that staging
> hasn't been merged after (obviously) 4 hours it means something is wrong (or
> I suppose there could be a networking issue between the servers doing the
> merge and our git repo).
>
> I deliberately don't configure my machine to send the merge success/fail
> emails because ... corp. IT reasons as you can tell these scripts to post
> something when they do fail, but I usually check manually in the mornings
> anyway and I can see on my server if the merge has failed. But obviously I
> failed to notice yesterday (it was 35 hours between staging update and
> merge) so it isn't an infallible system.
>

OK--just pushed the revert to staging.  Will wait till staging catches
up with master before proceeding.

Thanks for the help and explanations!

David

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

2017-01-11 Thread James 

Hello,


On 11/01/17 16:44, David Nalesnik wrote:

On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels  wrote:

David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM



Ok, so I will probably do

git revert HEAD

in my staging branch

and push it to origin/staging.

---

I won't attempt to clear the LSR queue in preparation for my patch
update (as I did) by running makelsr.py again.

When I update my issue, I'll simply add my snippet to snippets/new,
and leave updating the LSR to the future (when the frenched-score
snippet and my proposed snippet and whatever else appears will be
integrated)

Sorry my recipe caused a problem in this case.  Normally clearing
the old LSR queue first with makelsr.py would be fine.  But what
you suggest is also OK, as long as someone fixes the problem and
runs makelsr.py reasonably soon - before the next new snippet is
added (I can't run it myself - on my Windows Vista it always tries
to change all the \ to / or vice versa.)


I think the only problem is that @{MarkLines} should be replaced with
@code{MarkLines}.

I'm stuck in the middle of a make doc checking the change.  When I'm
through that, I'll revert the update.

Then I can push an update of the snippet to staging.  (But I'll save
the makelsr for later as James says.)

No problem, it's all a learning experience for me!


The staging merge runs every 4 hours - on my own server - so depending 
on when you eventually push to staging again, if you still see that 
staging hasn't been merged after (obviously) 4 hours it means something 
is wrong (or I suppose there could be a networking issue between the 
servers doing the merge and our git repo).


I deliberately don't configure my machine to send the merge success/fail 
emails because ... corp. IT reasons as you can tell these scripts to 
post something when they do fail, but I usually check manually in the 
mornings anyway and I can see on my server if the merge has failed. But 
obviously I failed to notice yesterday (it was 35 hours between staging 
update and merge) so it isn't an infallible system.


Regards

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

2017-01-11 Thread David Nalesnik 
On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels  wrote:
>
> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>
>
>> Ok, so I will probably do
>>
>> git revert HEAD
>>
>> in my staging branch
>>
>> and push it to origin/staging.
>>
>> ---
>>
>> I won't attempt to clear the LSR queue in preparation for my patch
>> update (as I did) by running makelsr.py again.
>>
>> When I update my issue, I'll simply add my snippet to snippets/new,
>> and leave updating the LSR to the future (when the frenched-score
>> snippet and my proposed snippet and whatever else appears will be
>> integrated)
>
> Sorry my recipe caused a problem in this case.  Normally clearing
> the old LSR queue first with makelsr.py would be fine.  But what
> you suggest is also OK, as long as someone fixes the problem and
> runs makelsr.py reasonably soon - before the next new snippet is
> added (I can't run it myself - on my Windows Vista it always tries
> to change all the \ to / or vice versa.)
>

I think the only problem is that @{MarkLines} should be replaced with
@code{MarkLines}.

I'm stuck in the middle of a make doc checking the change.  When I'm
through that, I'll revert the update.

Then I can push an update of the snippet to staging.  (But I'll save
the makelsr for later as James says.)

No problem, it's all a learning experience for me!

David

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

2017-01-11 Thread Trevor Daniels 

David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM


> Ok, so I will probably do
> 
> git revert HEAD
> 
> in my staging branch
> 
> and push it to origin/staging.
> 
> ---
> 
> I won't attempt to clear the LSR queue in preparation for my patch
> update (as I did) by running makelsr.py again.
> 
> When I update my issue, I'll simply add my snippet to snippets/new,
> and leave updating the LSR to the future (when the frenched-score
> snippet and my proposed snippet and whatever else appears will be
> integrated)

Sorry my recipe caused a problem in this case.  Normally clearing
the old LSR queue first with makelsr.py would be fine.  But what
you suggest is also OK, as long as someone fixes the problem and
runs makelsr.py reasonably soon - before the next new snippet is
added (I can't run it myself - on my Windows Vista it always tries 
to change all the \ to / or vice versa.)

Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel