http://codereview.appspot.com/5755058/diff/1/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):
http://codereview.appspot.com/5755058/diff/1/lily/page-layout-problem.cc#newcode343
lily/page-layout-problem.cc:343: return footnote_separator;
Uh, Mike?
You call a Scheme function
Hi David,
I am willing to support the development of LilyPond financially with small
amount of money regularly.
I am not sure I understand your payment plans. For example (quoting from
http://news.lilynet.net/?The-LilyPond-Report-24):
>
>- [*Lifesaver*] Minimum €0, cap €250 per month, monthly
Marek Klein writes:
> Hi David,
> I am willing to support the development of LilyPond financially with
> small amount of money regularly.
> I am not sure I understand your payment plans. For example (quoting
> from http://news.lilynet.net/?The-LilyPond-Report-24):
>
> * [Lifesaver] Minimum €0
Hi, the recent translation merge apparently made some wrong choices when
dealing with merge conflicts. Changes in staging have been overwritten
in the following files:
Documentation/snippets/centering-markup-on-note-heads-automatically.ly
Documentation/snippets/defining-an-engraver-in-scheme-amb
2012/3/6 Janek Warchoł
> On Tue, Mar 6, 2012 at 11:48 PM, Joe Neeman wrote:
> > 2012/3/6
> >
> >> Mike & all,
> >>
> >> i did a quick compile with patchset 36 and unfortunately didn't notice
> >> significant speedups from previous version.
> >
> >
> > Could you try the dev/jneem branch in git?
David Kastrup writes:
> Hi, the recent translation merge apparently made some wrong choices when
> dealing with merge conflicts. Changes in staging have been overwritten
> in the following files:
> And that affects a lot more than just translations. I have removed that
> commit from origin/sta
On Mar 7, 2012, at 8:48 AM, d...@gnu.org wrote:
> Given the level and amount of code you write, it might be worth
> investing the time rereading the garbage collection chapter of the Guile
> manual.
>
You're right that I know nothing about guile's garbage collection...it'd help
to know this. I
David Kastrup writes:
> David Kastrup writes:
>
>> Hi, the recent translation merge apparently made some wrong choices when
>> dealing with merge conflicts. Changes in staging have been overwritten
>> in the following files:
>
>> And that affects a lot more than just translations. I have remov
David Kastrup gnu.org> writes:
> I can reproduce the problems when merging. It would appear that the
> history of the translation branch got messed up at some point of time in
> a manner that git can't recognize how to merge properly anymore.
I don't know if this can help you, but I noticed the
David
On 7 March 2012 12:58, David Kastrup wrote:
> David Kastrup writes:
>
>> David Kastrup writes:
>>
>>> Hi, the recent translation merge apparently made some wrong choices when
>>> dealing with merge conflicts. Changes in staging have been overwritten
>>> in the following files:
>>
>>> And
On Wed, Mar 07, 2012 at 01:58:24PM +0100, David Kastrup wrote:
> David Kastrup writes:
>
> > I can reproduce the problems when merging. It would appear that the
> > history of the translation branch got messed up at some point of time in
> > a manner that git can't recognize how to merge properl
"m...@apollinemike.com" writes:
> On Mar 7, 2012, at 8:48 AM, d...@gnu.org wrote:
>
>> Given the level and amount of code you write, it might be worth
>> investing the time rereading the garbage collection chapter of the Guile
>> manual.
>>
>
> You're right that I know nothing about guile's garb
James writes:
> David
>
> On 7 March 2012 12:58, David Kastrup wrote:
>> David Kastrup writes:
>>
>>> David Kastrup writes:
>>>
Hi, the recent translation merge apparently made some wrong choices when
dealing with merge conflicts. Changes in staging have been overwritten
in the
Graham Percival writes:
> On Wed, Mar 07, 2012 at 01:58:24PM +0100, David Kastrup wrote:
>> David Kastrup writes:
>>
>> > I can reproduce the problems when merging. It would appear that the
>> > history of the translation branch got messed up at some point of time in
>> > a manner that git can
Julien Rioux writes:
> David Kastrup gnu.org> writes:
>> I can reproduce the problems when merging. It would appear that the
>> history of the translation branch got messed up at some point of time in
>> a manner that git can't recognize how to merge properly anymore.
>
> I don't know if this c
David Kastrup writes:
> David Kastrup writes:
>
>> Hi, the recent translation merge apparently made some wrong choices when
>> dealing with merge conflicts. Changes in staging have been overwritten
>> in the following files:
>
>> And that affects a lot more than just translations. I have remov
Julien Rioux writes:
> David Kastrup gnu.org> writes:
>> I can reproduce the problems when merging. It would appear that the
>> history of the translation branch got messed up at some point of time in
>> a manner that git can't recognize how to merge properly anymore.
>
> I don't know if this c
Le 07/03/2012 15:29, David Kastrup disait :
I see rebasing commits like
commit 24f5f986998c23a1cbac15024d58ca6497093cce
Author: Julien Rioux
Commit: Francisco Vila
Doc-de: Compilation fix for de/notation.
commit 12cfe6bafb8589b0780df84fb36981994ee8793a
Author: Till Paala
Commit: Francisc
David Kastrup writes:
> Julien Rioux writes:
>
>> David Kastrup gnu.org> writes:
>>> I can reproduce the problems when merging. It would appear that the
>>> history of the translation branch got messed up at some point of time in
>>> a manner that git can't recognize how to merge properly anym
Jean-Charles Malahieude writes:
> Le 07/03/2012 15:29, David Kastrup disait :
>>
>> I see rebasing commits like
>>
>> commit 24f5f986998c23a1cbac15024d58ca6497093cce
>> Author: Julien Rioux
>> Commit: Francisco Vila
>>
>> Doc-de: Compilation fix for de/notation.
>>
>> commit 12cfe6bafb8589b0
- Original Message -
From: "Graham Percival"
To: "David Kastrup"
Cc:
Sent: Wednesday, March 07, 2012 1:22 PM
Subject: Re: Bad translation merge
On Wed, Mar 07, 2012 at 01:58:24PM +0100, David Kastrup wrote:
David Kastrup writes:
> I can reproduce the problems when merging. It wo
Le 07/03/2012 17:06, David Kastrup disait :
Jean-Charles Malahieude writes:
Le 07/03/2012 15:29, David Kastrup disait :
which also appear in a version committed by their actual authors.
That's definitely not good. But I don't see how this would explain the
_loss_ of changes. Digging furthe
On Wed, Mar 07, 2012 at 05:27:08PM -, Phil Holmes wrote:
> As an improvement to patchy, wouldn't it be better for patchy to
> test for a "stop-patchy" branch and abort if it finds one? Then all
> that would be necessary to suspend the cron job would be to create a
> branch with that name.
No;
2012/3/7 David Kastrup :
>
> Hi, the recent translation merge apparently made some wrong choices when
> dealing with merge conflicts. Changes in staging have been overwritten
> in the following files:
>
> Documentation/snippets/centering-markup-on-note-heads-automatically.ly
> Documentation/snippe
Graham Percival writes:
> On Wed, Mar 07, 2012 at 05:27:08PM -, Phil Holmes wrote:
>> As an improvement to patchy, wouldn't it be better for patchy to
>> test for a "stop-patchy" branch and abort if it finds one? Then all
>> that would be necessary to suspend the cron job would be to create
Francisco Vila writes:
> 2012/3/7 David Kastrup :
>>
>> Hi, the recent translation merge apparently made some wrong choices when
>> dealing with merge conflicts. Changes in staging have been overwritten
>> in the following files:
>>
>> Documentation/snippets/centering-markup-on-note-heads-automa
David Kastrup writes:
> Don't rebase either origin and translation. Simple rule. Don't try
> being clever about it: being clever around git is a recipe for disaster.
> If you messed up your own repository (and that does not mean "merely"
> the state of the work tree, but the history of commits)
David Kastrup writes:
> David Kastrup writes:
>
>> Don't rebase either origin and translation. Simple rule. Don't try
>> being clever about it: being clever around git is a recipe for disaster.
>> If you messed up your own repository (and that does not mean "merely"
>> the state of the work tr
Hi,
one question: we can checkout a commit before merge commit and thus
"fix" master? So, the main problem is how to fix translation
properly?
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond
Janek Warchoł writes:
> Hi,
>
> one question: we can checkout a commit before merge commit and thus
> "fix" master? So, the main problem is how to fix translation
> properly?
We can't "fix" master that easily. You'll get a nice working tree in
that manner, but you can't push that to master. A
2012/3/7 Janek Warchoł
> On Wed, Mar 7, 2012 at 11:43 AM, Joe Neeman wrote:
> >
> > 2012/3/6 Janek Warchoł
> >> Actually, small/zero horizontal padding might give better results in
> >> some places, but that needs thorough investigation.
> >
> > Something that, FWIW, never happened with the pre
On Wed, Mar 7, 2012 at 10:47 PM, David Kastrup wrote:
> Janek Warchoł writes:
>
>> Hi,
>>
>> one question: we can checkout a commit before merge commit and thus
>> "fix" master? So, the main problem is how to fix translation
>> properly?
>
> We can't "fix" master that easily. You'll get a nice
David Kastrup writes:
> Francisco Vila writes:
>
>> I rebased by mistake (instead of merging) lilypond/translation into
>> staging and my reasoning was: provided that staging does 'make &&
>> make doc' and it has all the new work from translations, staging is
>> not damaged in any way, for now.
On Wed, Mar 7, 2012 at 10:50 PM, Joe Neeman wrote:
> 2012/3/7 Janek Warchoł
>>
>> On Wed, Mar 7, 2012 at 11:43 AM, Joe Neeman wrote:
>> >
>> > 2012/3/6 Janek Warchoł
>> >> Actually, small/zero horizontal padding might give better results in
>> >> some places, but that needs thorough investigati
Janek Warchoł writes:
> On Wed, Mar 7, 2012 at 10:47 PM, David Kastrup wrote:
>
>> I've created a rebased branch containing all the commits that were
>> dropped in the faulty merge, and merged that into translation (the
>> result is at dev/translation). I then merged that back into master (of
>
David Kastrup writes:
> Well, "somebody" will likely be me, of course. Sleep is overrated.
> make check is not all that slow, and I can leave the full doc build to
> Patchy (assuming he is still on regular duty: there is actually no
> reason why he shouldn't be). That leaves the translations.
Hello,
On 7 March 2012 23:42, David Kastrup wrote:
> David Kastrup writes:
>
>> Well, "somebody" will likely be me, of course. Sleep is overrated.
>> make check is not all that slow, and I can leave the full doc build to
>> Patchy (assuming he is still on regular duty: there is actually no
>> r
James writes:
> On 7 March 2012 23:42, David Kastrup wrote:
>> David Kastrup writes:
>>
>>> Well, "somebody" will likely be me, of course. Sleep is overrated.
>>> make check is not all that slow, and I can leave the full doc build to
>>> Patchy (assuming he is still on regular duty: there is a
hello,
On 8 March 2012 00:04, David Kastrup wrote:
> James writes:
>
>> On 7 March 2012 23:42, David Kastrup wrote:
>>> David Kastrup writes:
>>>
Well, "somebody" will likely be me, of course. Sleep is overrated.
make check is not all that slow, and I can leave the full doc build to
Hello,
On 8 March 2012 00:04, David Kastrup wrote:
...
> Huh? Why pause? I wrote "hopefully master soon". Just let the beast
> run as scheduled.
This is what it reports as it started (just FYI)
--snip--
emote: Counting objects: 272, done.
remote: Compressing objects: 100% (30/30), done.
rem
James writes:
> Hello,
>
> On 8 March 2012 00:04, David Kastrup wrote:
> ...
>> Huh? Why pause? I wrote "hopefully master soon". Just let the beast
>> run as scheduled.
>
> This is what it reports as it started (just FYI)
>
> --snip--
>
> emote: Counting objects: 272, done.
> remote: Compress
Boom!
All done.
-- Forwarded message --
From:
Date: 8 March 2012 00:29
Subject: Patchy email
To: pkx1...@gmail.com
Merged staging, now at: 2944a83e59f487894a214769392ce27289accb71
Success: ./autogen.sh --noconfigure
Success: ../co
David Kastrup writes:
> We currently have the situation that bad commits on the translation
> branch have caused a loss of work in our main repository. While I am
> trying to sort out the damage, it is not helpful if you keep pushing new
> material to the translation branch. Please refrain from
> Once you have checked that the recent fixes have not caused any of
> your work to get lost and the criss-cross merge has been done, you
> can continue committing to the translation branch.
>
> I apologize for the inconvenience.
Thanks a lot for fixing this. Do you recommend a modification of
Werner LEMBERG writes:
>> Once you have checked that the recent fixes have not caused any of
>> your work to get lost and the criss-cross merge has been done, you
>> can continue committing to the translation branch.
>>
>> I apologize for the inconvenience.
>
> Thanks a lot for fixing this. Do
45 matches
Mail list logo
