Re: Branch management

[Urs Liska]

Am 12.08.2016 um 07:21 schrieb littlesincanada:
> Hi,
>
> On 11/08/16 21:18, David Kastrup wrote:
>> littlesincanada  writes:
>>
>>> On the face of it, a rebase is the obvious solution, but I'm told that
>>> it's a cardinal sin to rebase commits that have already been pushed.
>> So forget about that cardinal sin and just rebase.  You'll find that
>> you'll no longer be able to push the rebased branch since it is not a
>> fast forward.  So you first need to delete and then repush it, like
>>
>> git push origin :refs/heads/dev/rlittle
>> git push origin HEAD:refs/heads/dev/rlittle
>>
>> Of course, make very sure that your current HEAD is in the state you
>> want to see remotely before doing the deletion.
>>
> Ah, I see. Delete the remote branch and repush a new branch from the
> current master head.
> OK, I will give it a try tomorrow sometime. Many thanks.

If, as you say, you only have one commit on your branch you can also
just copy that commit to a new branch and later delete the old branch:

git checkout master
git checkout -b my/new/branch
git cherry-pick commit-id-from-old-branch

... later ...
git branch -D dev/rlittle
git push origin :refs/heads/dev/rlittle

This *may* "feel" somewhat safer without the rebasing.
Urs
>
> Cheers,
> Ralph
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel


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

Re: Branch management

[littlesincanada]

Hi,

On 11/08/16 21:18, David Kastrup wrote:

littlesincanada  writes:


On the face of it, a rebase is the obvious solution, but I'm told that
it's a cardinal sin to rebase commits that have already been pushed.

So forget about that cardinal sin and just rebase.  You'll find that
you'll no longer be able to push the rebased branch since it is not a
fast forward.  So you first need to delete and then repush it, like

git push origin :refs/heads/dev/rlittle
git push origin HEAD:refs/heads/dev/rlittle

Of course, make very sure that your current HEAD is in the state you
want to see remotely before doing the deletion.

Ah, I see. Delete the remote branch and repush a new branch from the 
current master head.

OK, I will give it a try tomorrow sometime. Many thanks.

Cheers,
Ralph

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

Re: Branch management

[David Kastrup]

littlesincanada  writes:

> Hi Devs,
> It's a long time since I pushed any Lilypond dev work to my dev branch
> dev/rlittle. About 9 years to be precise. :o
> OK, time that situation changed.
>
> The only commit on that branch is a first pass at a Braille output
> option base. Things have moved on and I'm working on it some more, but
> the base on which it is based is s old. So old in fact that I can
> no longer build it. It seems that the build tools themselves have
> moved on.
>
> On the face of it, a rebase is the obvious solution, but I'm told that
> it's a cardinal sin to rebase commits that have already been pushed.

To a branch of public interest.  Even then, branches like our staging
branch are intended to be reset frequently.

And developer branches are up to the discretion of the developer.

So forget about that cardinal sin and just rebase.  You'll find that
you'll no longer be able to push the rebased branch since it is not a
fast forward.  So you first need to delete and then repush it, like

git push origin :refs/heads/dev/rlittle
git push origin HEAD:refs/heads/dev/rlittle

Of course, make very sure that your current HEAD is in the state you
want to see remotely before doing the deletion.

-- 
David Kastrup

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

Branch management

[littlesincanada]

Hi Devs,
It's a long time since I pushed any Lilypond dev work to my dev branch 
dev/rlittle. About 9 years to be precise. :o

OK, time that situation changed.

The only commit on that branch is a first pass at a Braille output 
option base. Things have moved on and I'm working on it some more, but 
the base on which it is based is s old. So old in fact that I can no 
longer build it. It seems that the build tools themselves have moved on.


On the face of it, a rebase is the obvious solution, but I'm told that 
it's a cardinal sin to rebase commits that have already been pushed.


So what I figure I need to do is revert the changes and apply an update 
that is current with master (which I have done locally, and it compiles 
and runs), taking into account how things have moved on but that still 
leaves my branch anchored 9 years into the past.


Any ideas how I should proceed?

Cheers,
Ralph

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

Re: Doc: CG update Indenting with vim section (issue 302340043 by mark.opu...@googlemail.com)

[mark . opus11]

On 2016/08/06 13:26:43, Carl wrote:

Thanks for doing this -- it helps me understand better how things

work, and

gives an example of a more robust set of vim settings.



https://codereview.appspot.com/302340043/diff/1/Documentation/contributor/programming-work.itexi

File Documentation/contributor/programming-work.itexi (left):



https://codereview.appspot.com/302340043/diff/1/Documentation/contributor/programming-work.itexi#oldcode394

Documentation/contributor/programming-work.itexi:394: autocmd

BufWritePre *

:%s/\s\+$//e
I think we should leave the removal of trailing whitespace in our

recommended

.vimrc



This eliminates the problem of whitespace errors (which git will track

and

complain about).



I agree that it doesn't belong in the indenting section, but I think

it should

still be part of our recommendations for using vim.


Yes, good idea, I'll add the trailing whitespace fix back in. There's
not
really a better place for this stuff at the moment, unless we want to
make
a dedicated VIM section.

https://codereview.appspot.com/302340043/

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

Re: Issue 4936: look up "mf" for default initial volume (issue 308890043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

On 2016/08/10 23:05:23, c_sorensen wrote:


When writing congregational hymns, dynamics are very seldom included.



But I may wish to generate practice midi from my engraving (I

regularly do

it).  It would be nice to be able to define my own default midi volume

that

would apply.


This is a frequent use case for me too.  I've always handled it by
removing the dynamic engraver.  Then I specify dynamics anywhere I
please without having them appear in the printed score.

https://codereview.appspot.com/308890043/

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

Re: Issue 4936: look up "mf" for default initial volume (issue 308890043 by nine.fierce.ball...@gmail.com)

[dak]

On 2016/08/10 23:05:23, c_sorensen wrote:


On 8/10/16 4:17 PM, mailto:"nine.fierce.ball...@gmail.com;
 wrote:



>David, do you have advice on the direction to take regarding the
>comments on this thing in midi.scm?
>
> (define-public dynamic-default-volume 0.71)
>
>To me it seems unnecessary (the user should specify a dynamic if a
>specific dynamic is desired)



I'm not David, but I'd like to describe my use case.



When writing congregational hymns, dynamics are very seldom included.



But I may wish to generate practice midi from my engraving (I

regularly do

it).  It would be nice to be able to define my own default midi volume

that

would apply.



>and the wrong place for a default anyway.
>It should be in a context if it needs to be anywhere, right?



What context would it be defined in?  the midi performer can exist in

a

variety of contexts.



I suppose that different contexts might have different default midi
volumes.



So I guess the default midi volume might be defined in the Score

context,

and then any lower contexts could override the default midi volume.

And

of course, you are right that this should then become a documented

context

property.



So at any rate, I think the public definition should be eliminated

from

midi.scm, regardless of whether or not somebody has used it.


If somebody has used it, it would have had no effect.  I think it is
saner to remove it so that the code trying to set it actually has a
chance to trigger an error (which usually will be dealt with by removing
the ineffectual statement).

With regard to your use case: anything that cannot be dealt with by
using the equivalent of
\score {
  { c'-\hide\ppp }
  \layout {}
  \midi { }
}

\score {
  { g'-\hide\fff }
  \layout {}
  \midi { }
}

Maybe we should also provide the equivalent \loudness "ppp" or so that
only affects Midi (and can stand on its own rather than as an
articulation and thus may also be used in a \midi block)?  At any rate,
this does not appear to affect Dan's patch.  Removing
dynamic-default-volume makes separate sense, and since this patch deals
with default volumes, wrapping its removal into this series would be ok
as well, but it should be a separate commit anyway since it is a
separate identifiable isolated change.


If eliminating causes them problems, they can add that definition to

their

ly files.


Well, at some point of time adding mystic incantations that do nothing
at all stops making a lot of sense.  But again: that's not really the
topic of this issue/review.

https://codereview.appspot.com/308890043/

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

Re: Programming Language

[David Kastrup]

Ricardo Wurmus  writes:

> Hi Conor,
>
> David Kastrup  writes:
>
>> For extending LilyPond, you need Scheme.  Scheme knowledge is only of
>> limited marketing value but of course the general kind of solving
>> programming tasks from within a fourth generation extension language may
>> still be reasonably relevant.
>
> Scheme is a very good language to know.  It is also reasonably close to
> Clojure, which seems to be quite popular these days.



That kind of popularity is akin to the kid in school that would let you
copy their homework but you'd rather not since it may be formally right
according to some criteria but you'd get busted the moment someone looks
closer or asks a question.

-- 
David Kastrup

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

Re: Programming Language

[Urs Liska]

Am 10.08.2016 um 19:09 schrieb David Kastrup:
> C++ is a good career move, but the C++ in LilyPond's code base is of
> rather mixed quality and of rather mixed age: the early parts had to
> rely on the features available in early language standards.  So C++
> skills acquired while working with LilyPond may be only moderately
> representative for the language as such.

You can also translate this to: "Learning C++ is a good idea. But you
shouldn't learn it through LilyPond but rather just learn it (somehow)
and *then* adapt your general knowledge when you want to contribute to
LilyPond."

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

Re: Programming Language

[Ricardo Wurmus]

Hi Conor,

David Kastrup  writes:

> For extending LilyPond, you need Scheme.  Scheme knowledge is only of
> limited marketing value but of course the general kind of solving
> programming tasks from within a fourth generation extension language may
> still be reasonably relevant.

Scheme is a very good language to know.  It is also reasonably close to
Clojure, which seems to be quite popular these days.

~~ Ricardo


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