"m...@apollinemike.com" writes:
> On Oct 25, 2011, at 3:46 PM, David Kastrup wrote:
>>
>> Well, my .git/config has
>> [remote "origin"]
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> url = ssh://git.sv.gnu.org/srv/git/lilypond.git
>> fetch = +refs/heads/dev/staging:refs/remotes
On Oct 25, 2011, at 3:46 PM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 25, 2011, at 3:36 PM, David Kastrup wrote:
>>
>>"m...@apollinemike.com" writes:
>>
>>And now I have two extra branches (staging/HEAD and
>>origin/dev/staging/HEAD) that I can't
"m...@apollinemike.com" writes:
> On Oct 25, 2011, at 3:36 PM, David Kastrup wrote:
>
> "m...@apollinemike.com" writes:
>
> And now I have two extra branches (staging/HEAD and
> origin/dev/staging/HEAD) that I can't seem to get rid of. Any
> suggestions?
>
On Oct 25, 2011, at 3:36 PM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> And now I have two extra branches (staging/HEAD and origin/dev/staging/HEAD)
>> that I can't seem to get rid of. Any suggestions?
>
> Use an editor on .git/config to clean up, and find and delete those
>
"m...@apollinemike.com" writes:
> And now I have two extra branches (staging/HEAD and origin/dev/staging/HEAD)
> that I can't seem to get rid of. Any suggestions?
Use an editor on .git/config to clean up, and find and delete those
files from .git/refs that represent the bad branches.
Sometime
On Oct 25, 2011, at 3:12 PM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 25, 2011, at 3:06 PM, Colin Campbell wrote:
>>
>>> On 11-10-25 05:40 AM, m...@apollinemike.com wrote:
Hey all,
I tried:
git remote add -ft dev/staging -m dev/staging stagin
"m...@apollinemike.com" writes:
> On Oct 25, 2011, at 3:06 PM, Colin Campbell wrote:
>
>> On 11-10-25 05:40 AM, m...@apollinemike.com wrote:
>>> Hey all,
>>>
>>> I tried:
>>>
>>> git remote add -ft dev/staging -m dev/staging staging
>>> git://git.sv.gnu.org/lilypond.git/
That adds a separate r
On Oct 25, 2011, at 3:06 PM, Colin Campbell wrote:
> On 11-10-25 05:40 AM, m...@apollinemike.com wrote:
>> Hey all,
>>
>> I tried:
>>
>> git remote add -ft dev/staging -m dev/staging staging
>> git://git.sv.gnu.org/lilypond.git/
>>
>> And then
>>
>> git branch foo staging/dev/staging
>> git c
On 11-10-25 05:40 AM, m...@apollinemike.com wrote:
Hey all,
I tried:
git remote add -ft dev/staging -m dev/staging staging
git://git.sv.gnu.org/lilypond.git/
And then
git branch foo staging/dev/staging
git checkout foo
git apply foo.diff (where foo.diff are all of my changes)
git commit -a
On Tue, 25 Oct 2011 11:49:58 +0200, David Kastrup wrote:
Graham Percival writes:
On Tue, Oct 25, 2011 at 10:56:23AM +0200, David Kastrup wrote:
"m...@apollinemike.com" writes:
> git mikesol@mikesol-laptop:~/lilypond-git$ git rebase
origin/dev/staging
> fatal: Needed a single revision
> in
Graham Percival writes:
> On Tue, Oct 25, 2011 at 10:56:23AM +0200, David Kastrup wrote:
>> "m...@apollinemike.com" writes:
>>
>> > git mikesol@mikesol-laptop:~/lilypond-git$ git rebase origin/dev/staging
>> > fatal: Needed a single revision
>> > invalid upstream origin/dev/staging
>>
>> git b
On Tue, Oct 25, 2011 at 10:56:23AM +0200, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
> > git mikesol@mikesol-laptop:~/lilypond-git$ git rebase origin/dev/staging
> > fatal: Needed a single revision
> > invalid upstream origin/dev/staging
>
> git branch -r lists nothing? Anyhow: I
"m...@apollinemike.com" writes:
> On Oct 25, 2011, at 8:36 AM, David Kastrup wrote:
>
>> "m...@apollinemike.com" writes:
>>
>>> On Oct 25, 2011, at 7:08 AM, David Kastrup wrote:
>>>
"m...@apollinemike.com" writes:
> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>
>
On Oct 25, 2011, at 8:36 AM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 25, 2011, at 7:08 AM, David Kastrup wrote:
>>
>>> "m...@apollinemike.com" writes:
>>>
On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
> git fetch
> git rebase origin/dev/stagin
"m...@apollinemike.com" writes:
> On Oct 25, 2011, at 7:08 AM, David Kastrup wrote:
>
>> "m...@apollinemike.com" writes:
>>
>>> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>>>
git fetch
git rebase origin/dev/staging
git push origin HEAD:dev/staging
>>>
>>> From the rebase
On Oct 24, 2011, at 11:05 PM, David Kastrup wrote:
>
>
>> 2) A reminder in 10.9.5 to change versions when moving stuff to
>> Documents/snippets/new would be great too.
>
> I am not sure whether that is not something Graham wants to do himself.
> However, I think it is harmless enough to do it o
On Oct 25, 2011, at 7:08 AM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>>
>>> git fetch
>>> git rebase origin/dev/staging
>>> git push origin HEAD:dev/staging
>>
>> From the rebase command on my local branch, I got:
>>
>> fat
"m...@apollinemike.com" writes:
> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>
>> git fetch
>> git rebase origin/dev/staging
>> git push origin HEAD:dev/staging
>
> From the rebase command on my local branch, I got:
>
> fatal: Needed a single revision
> invalid upstream origin/dev/staging
On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
> git fetch
> git rebase origin/dev/staging
> git push origin HEAD:dev/staging
>From the rebase command on my local branch, I got:
fatal: Needed a single revision
invalid upstream origin/dev/staging
Any hints on what to do?
Cheers,
MS
_
"m...@apollinemike.com" writes:
> I now see what the problem is. I had updated the version number all
> the snippets that needed updating, but all of the offending snippets
> are in the .tely files. The \version statement for these snippets is
> not in the snippets themselves (I thought they we
"m...@apollinemike.com" writes:
> 3) When patches come out and are on review, especially when the
> patches go through the review cycle more than once, it'd be great if
> this sort of thing were addressed. Originally I didn't add convert-ly
> rules because I wa
hat would help a lot.
2) A reminder in 10.9.5 to change versions when moving stuff to
Documents/snippets/new would be great too.
3) When patches come out and are on review, especially when the patches go
through the review cycle more than once, it'd be great if this sort of thing
were addr
"m...@apollinemike.com" writes:
> On Oct 24, 2011, at 5:29 PM, David Kastrup wrote:
>
>> The problem is that eventually, somebody else _will_ run
>> scripts/auxiliar/update-with-convert-ly and then those files get
>> "fixed" again if the version string indicates they have not yet been
>> fixed.
>
On Oct 24, 2011, at 5:29 PM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>>
>>> "m...@apollinemike.com" writes:
>>>
On Oct 24, 2011, at 4:29 PM, David Kastrup wrote:
>
> Mike has pushed directly 671b7b634088
"m...@apollinemike.com" writes:
> On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
>
>> "m...@apollinemike.com" writes:
>>
>>> On Oct 24, 2011, at 4:29 PM, David Kastrup wrote:
>>>
Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to
master, as far as I can see
On Oct 24, 2011, at 5:12 PM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 24, 2011, at 4:29 PM, David Kastrup wrote:
>>
>>>
>>> Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to
>>> master, as far as I can see without any discussion and without going
>>
"m...@apollinemike.com" writes:
> On Oct 24, 2011, at 4:29 PM, David Kastrup wrote:
>
>>
>> Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to
>> master, as far as I can see without any discussion and without going
>> through staging.
>>
>
> This got to patch push after going
On Oct 24, 2011, at 4:29 PM, David Kastrup wrote:
>
> Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to
> master, as far as I can see without any discussion and without going
> through staging.
>
This got to patch push after going through a countdown.
As for staging, I'm stil
Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to
master, as far as I can see without any discussion and without going
through staging.
I changed the rules somewhat in order make them get useful output for
\once\override as well, and pushed this directly to master as a
followup
Looks good enough to me.
http://codereview.appspot.com/5050046/diff/1/python/convertrules.py
File python/convertrules.py (right):
http://codereview.appspot.com/5050046/diff/1/python/convertrules.py#newcode3241
python/convertrules.py:3241: str = re.sub
(r"Stem\s+#'transparent\s*=\s*##t", r"Stem
LGTM
http://codereview.appspot.com/5050046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Passes make and reg tests
http://codereview.appspot.com/5050046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
nvert-ly rules for flag syntax changes
Please review this at http://codereview.appspot.com/5050046/
Affected files:
M python/convertrules.py
Index: python/convertrules.py
diff --git a/python/convertrules.py b/python/convertrules.py
index
b1e3fefd453112ca010cc1c00144874f818
Hi Reinhold (et al),
Unfortunately, I don't have the time now to investigate better
defaults
myself, but with these defaults, the scores simply look terrible.
+1
Another problem I've found (but have yet to minimally-exemplify) is
that a manual \pageBreak will often [always?] lead to a pag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since the new vertical layout engine completely changes the way the layout
works, in particular, many paper variables no longer work and
VerticalAxisGroup #'minimum-Y-extent also no longer works, we really need
proper convert-ly rules to up
ml/lilypond-devel/2008-12/msg00715.html
>>
>> Just to clarify, the renames are:
>>
>> dispatcher --> ly:dispatcher?
>> listener --> ly:listener?
>>
>> There are no other C++ predicate callbacks that have this problem.
>>
>> _
dispatcher --> ly:dispatcher?
> listener --> ly:listener?
>
> There are no other C++ predicate callbacks that have this problem.
>
> ________
>
> Should I make convert-ly rules for them?
No; if someone complains, figure what to do af
dicate callbacks that have this problem.
Should I make convert-ly rules for them?
I'm leaning against it for the following reasons:
1) The chance that someone uses these predicates is *very* slim, since
there is minimal interaction with the Dispatcher a
On Wed, Jul 08, 2009 at 11:14:08AM -0600, Carl D. Sorensen wrote:
> On 7/8/09 8:41 AM, "John Mandereau" wrote:
>
> > 009/7/7 Graham Percival :
> >> I'd just like to fix that one area, plus any new items.
> >
> > I'm not sure what you mean; do you expect somebody to quickly add word
> > boundarie
2009/7/8 Carl D. Sorensen :
> Such a function would ease the writing of *new* rules, which is what I think
> Graham's main emphasis is.
>
> I believe that it's clearly *not* worth it to fix old rules; there is *no*
> benefit to fixing old rules if they're not breaking. If they do break, we
> can f
On 7/8/09 8:41 AM, "John Mandereau" wrote:
> 009/7/7 Graham Percival :
>> I'm not, but almost all updates are in the form
>> \\oldCommand -> \\newCommand
>>
>> I suppose that somebody might have tried to speed up convert-ly
>> processing by doing
>> \\old -> \\new
>> and leaving the "Comman
009/7/7 Graham Percival :
> I'm not, but almost all updates are in the form
> \\oldCommand -> \\newCommand
>
> I suppose that somebody might have tried to speed up convert-ly
> processing by doing
> \\old -> \\new
> and leaving the "Command" out (thereby using one rule, instead of
> two rules), b
On Mon, Jul 06, 2009 at 11:14:13PM +0200, John Mandereau wrote:
> Le samedi 04 juillet 2009 à 01:58 -0700, Graham Percival a écrit :
> > arpeggio* should have \\ as well. Also, they should also be
> > matched with full words. In fact, 99% of the convert-ly rules
> > need to
Le samedi 04 juillet 2009 à 01:58 -0700, Graham Percival a écrit :
> arpeggio* should have \\ as well. Also, they should also be
> matched with full words. In fact, 99% of the convert-ly rules
> need to match a complete word. According to Daniel Hulme,
> "\\octave\b" w
rrowDown", str)
...
--
arpeggio* should have \\ as well. Also, they should also be
matched with full words. In fact, 99% of the convert-ly rules
need to match a complete word. According to Daniel Hulme,
"\\octave\b" would work fine.
1) Could somebody verify this (look in
Hi Max,
2008/12/22 Maximilian Albert :
> 2008/12/22 Maximilian Albert :
>> Should convert-ly rules be formulated so that Scheme-version
>> of commands like the above are also taken into account?
>
> Never mind, I just saw that the rule for \center-align already has
> this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 22. Dezember 2008 schrieb Maximilian Albert:
> 2008/12/22 Maximilian Albert :
> > Should convert-ly rules be formulated so that Scheme-version
> > of commands like the above are also taken into account?
>
> Never mind
2008/12/22 Maximilian Albert :
> Should convert-ly rules be formulated so that Scheme-version
> of commands like the above are also taken into account?
Never mind, I just saw that the rule for \center-align already has
this. So here is a patch for \bigger. In fact, the former reads
\larger). A
corresponding convert-ly rule does exist, but it explicitly checks for
the backslash in front of the command. So the above line was left
unchanged, which made lilypond choke. Should convert-ly rules be
formulated so that Scheme-version of commands like the above are also
taken into account?
49 matches
Mail list logo
