As an alternative, I do all my local (doc)
changes in separate branches. When one is
ready to push I fetch and merge origin/master
into my local branch master, cherrypick the
commits I want to submit and push. It's
slightly more work, but means I can work
on several updates at the same time in
OK. I'll look at it.
Trevor
- Original Message -
From: Graham Percival [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: lily-devel lilypond-devel@gnu.org
Sent: Monday, August 18, 2008 1:09 AM
Subject: percussion
Trevor,
I dumped a bit of info about percussion into MIDI. It'll need to
2008/8/18 Reinhold Kainhofer [EMAIL PROTECTED]:
If I'll ever get bored (as if that could ever happen!), I'll add an ellipse
stencil.
I tried using a rounded box, but unfortunately the rounded box will be filled,
thus overprinting the box for the pedal...
It could work well if the rounded-box
Some time in the past, there was a request for a separate git
repository/branch[1] for documentation, with the idea that more people could
be approved for push access on the docs repository/branch than would be
approved for push access on the code.
I think it would also be easier to have a
Graham
I've redrafted this to make it presentable but just left a TODO to expand
it, as I know nothing of percussion. I'll ask Stefan to check it out and
suggest any additions and/or examples. I'll push it as soon as I can
compile the NR to check my edits. The fretboard stuff is still
You can limit yourself to those by doing
git log -- lily/ scm/
I think bisect supports that too.
On Mon, Aug 18, 2008 at 11:49 AM, Carl D. Sorensen [EMAIL PROTECTED] wrote:
Some time in the past, there was a request for a separate git
repository/branch[1] for documentation, with the idea
Le 16.08.2008 21:05, Han-Wen Nienhuys disait :
Hi there,
please, if you find yourself creating graphs like the attached, invest
some moments of your time in rebasing your changes. It gets hard to
see what is going on here.
Sorry about this mess. I don't know how this happened.
I promise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 18. August 2008 schrieb Han-Wen Nienhuys:
On Sun, Aug 17, 2008 at 9:10 PM, Reinhold Kainhofer
[EMAIL PROTECTED] wrote:
Attached is a patch for stencil.scm, which adds a make-line-stencil that
does exactly that: You call it as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 18. August 2008 schrieb Reinhold Kainhofer:
Am Montag, 18. August 2008 schrieb Han-Wen Nienhuys:
On Sun, Aug 17, 2008 at 9:10 PM, Reinhold Kainhofer
[EMAIL PROTECTED] wrote:
Attached is a patch for stencil.scm, which adds a
2008/8/18 Carl D. Sorensen [EMAIL PROTECTED]:
Some time in the past, there was a request for a separate git
repository/branch[1] for documentation, with the idea that more people could
be approved for push access on the docs repository/branch than would be
approved for push access on the code.
On Fri, 2008-08-15 at 20:01 +0200, Werner LEMBERG wrote:
They can usually do that if you can limit the range to a single
release.
I've done bisecting. This is the problematic commit:
commit 2b8a93c3007d1789ac67c86b0ed63fbae003fc6e
Author: Joe Neeman [EMAIL PROTECTED]
Date: Mon
Before that, the bad-spacing.ly and good-spacing.ly give the same
result.
Fixed in git
Thanks!
(with a regtest!)
:-) I always try to write my bug reports so that they can be used as
regtests with just minimal editing.
Werner
___
2008/8/14 Graham Percival [EMAIL PROTECTED]:
Han-Wen, did you have any thoughts about the separate git tree
for docs email? One way or another, there's two doc writers who
should be able to push to the normal git tree for docs (whether
that's part of master or a separate one).
2008/8/18 Jean-Charles Malahieude [EMAIL PROTECTED]:
Sorry about this mess. I don't know how this happened.
I promise to do my best to avoid any reiteration, unless shutdown.
Ah, got it. You made some changes and committed, then you wanted to
update your branch with upstream (i.e.
2008/8/18 Reinhold Kainhofer [EMAIL PROTECTED]:
What I usually do is to either
1) First pull and then commit (only if I have not yet locally committed any
changes!)
2) If I already have local commits, like in this case, I do a
git fetch
which will not update the current files, but
2008/8/18 Reinhold Kainhofer [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 18. August 2008 schrieb Han-Wen Nienhuys:
On Sun, Aug 17, 2008 at 9:10 PM, Reinhold Kainhofer
[EMAIL PROTECTED] wrote:
Attached is a patch for stencil.scm, which adds a
2008/8/18 Reinhold Kainhofer [EMAIL PROTECTED]:
Done, patch is attached. Okay to apply?
Reinhold, this is great!
I've noticed you tagged this new markup command as music; although
I'm fine with it, I wonder if there would be a proper way to regroup
all fret-diagrams and harp-pedal-diagrams in
On 8/18/08 3:41 PM, Valentin Villenave [EMAIL PROTECTED] wrote:
2008/8/18 Reinhold Kainhofer [EMAIL PROTECTED]:
Done, patch is attached. Okay to apply?
Reinhold, this is great!
I've noticed you tagged this new markup command as music; although
I'm fine with it, I wonder if there would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 18. August 2008 schrieb Neil Puttock:
2008/8/18 Reinhold Kainhofer [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 18. August 2008 schrieb Han-Wen Nienhuys:
On Sun, Aug 17, 2008 at 9:10 PM, Reinhold
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 18. August 2008 schrieb Valentin Villenave:
I've noticed you tagged this new markup command as music; although
I'm fine with it, I wonder if there would be a proper way to regroup
all fret-diagrams and harp-pedal-diagrams in a same
On 8/18/08 4:19 PM, Reinhold Kainhofer [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 18. August 2008 schrieb Valentin Villenave:
I've noticed you tagged this new markup command as music; although
I'm fine with it, I wonder if there would be a proper
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 18. August 2008 schrieb Carl D. Sorensen:
P.S. Reinhold, I haven't checked the code yet. Have you put
harp-diagram-details as part of the text interface? I think it should go
there, since it is a markup.
No, I haven't. I simply looked
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 18. August 2008 schrieb John Mandereau:
BTW I don't know how you want to handle dev/texi2html merging,
git checkout master
git merge dev/texi2html
Done. Everything will work ;-)
but I prefer merging over rebasing:
In this case, I
On 8/18/08 4:29 PM, Reinhold Kainhofer [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 18. August 2008 schrieb Carl D. Sorensen:
P.S. Reinhold, I haven't checked the code yet. Have you put
harp-diagram-details as part of the text interface? I think it
2008/8/18 Reinhold Kainhofer [EMAIL PROTECTED]:
lilypond --version produces 2.11.56 here. Why should I be using 2.11.57?
Because you're implementing features which aren't available in release 2.11.56.
Regards,
Neil
___
lilypond-devel mailing list
2008/8/19 Carl D. Sorensen [EMAIL PROTECTED]:
I like instrument as the category.
Yes. instrument is the way to go indeed.
Maybe Instrument-specific markups, since we are talking about an appendix
of all defined markups?
Yes. Instrument-specific markups is great -- and self-explanatory
On 8/18/08 4:58 PM, Valentin Villenave [EMAIL PROTECTED] wrote:
2008/8/19 Carl D. Sorensen [EMAIL PROTECTED]:
I like instrument as the category.
Yes. instrument is the way to go indeed.
Maybe Instrument-specific markups, since we are talking about an appendix
of all defined markups?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Dienstag, 19. August 2008 schrieb Neil Puttock:
2008/8/18 Reinhold Kainhofer [EMAIL PROTECTED]:
lilypond --version produces 2.11.56 here. Why should I be using 2.11.57?
Because you're implementing features which aren't available in release
On Tue, 19 Aug 2008 01:11:51 +0200
Reinhold Kainhofer [EMAIL PROTECTED] wrote:
Am Dienstag, 19. August 2008 schrieb Neil Puttock:
2008/8/18 Reinhold Kainhofer [EMAIL PROTECTED]:
lilypond --version produces 2.11.56 here. Why should I be using
2.11.57?
Because you're implementing
On 8/18/08 4:47 PM, Carl D. Sorensen [EMAIL PROTECTED] wrote:
applies to TextScript objects. (I've stated this twice, because I'm talking
about two different directions -- from the grob to the property and from the
grob to the property).
Of course I meant from the grob to the property and
On Mon, Aug 18, 2008 at 7:47 PM, Carl D. Sorensen [EMAIL PROTECTED] wrote:
Perhaps we should define a new interface --
instrument-specific-markup-interface. It would contain
fret-diagram-details, harp-pedal-details, clarinet-diagram-details (once the
woodwind diagrams get added, etc. Then
If we start adding a lot of (occasional) contributors, I propose we
use the git.or.cz fork mechanism. People can then publish their
changes, and it's easy for the maintainers to pull/cherry-pick thoses.
On Mon, Aug 18, 2008 at 5:01 PM, John Mandereau
[EMAIL PROTECTED] wrote:
2008/8/18 Carl D.
On Mon, Aug 18, 2008 at 6:37 PM, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
If we start adding a lot of (occasional) contributors, I propose we
use the git.or.cz fork mechanism. People can then publish their
changes, and it's easy for the maintainers to pull/cherry-pick thoses.
I believe
33 matches
Mail list logo
