Re: Staging Broken with last makelsr - incorrect TexInfo commandformat
On Wed, Jan 11, 2017 at 10:44 AM, David Nalesnikwrote: > 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
On Wed, Jan 11, 2017 at 1:52 PM, David Kastrupwrote: > 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
David Nalesnikwrites: > 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
On Wed, Jan 11, 2017 at 12:31 PM, David Kastrupwrote: > 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
David Nalesnikwrites: > 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
On Wed, Jan 11, 2017 at 10:59 AM, Jameswrote: > 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
Hello, On 11/01/17 16:44, David Nalesnik wrote: On Wed, Jan 11, 2017 at 10:25 AM, Trevor Danielswrote: 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
On Wed, Jan 11, 2017 at 10:25 AM, Trevor Danielswrote: > > 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
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