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
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
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
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 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
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.
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:
> 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: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
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
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
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
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)
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
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
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
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;
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
- 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 pro
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
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
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
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
it hit the fan. Apparently I was not fast enough, and
>> somebody ran the staging-merge on the bad translation merge.
>
> I think that James was correct to do this -- or rather James'
> computer correctly ran the cronjob scheduled for every six hours.
> I don't think 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 will try to figure out what happened here. Please don't merge the
>>> translation br
#x27;t recognize how to merge properly anymore.
> >
> > I will try to figure out what happened here. Please don't merge the
> > translation branch to staging while I try figuring this out.
>
> Ok, the shit hit the fan. Apparently I was not fast enough, and
> somebody ran
t;> a manner that git can't recognize how to merge properly anymore.
>>
>> I will try to figure out what happened here. Please don't merge the
>> translation branch to staging while I try figuring this out.
>
> Ok, the shit hit the fan. Apparently I was not fa
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
ed here. Please don't merge the
> translation branch to staging while I try figuring this out.
Ok, the shit hit the fan. Apparently I was not fast enough, and
somebody ran the staging-merge on the bad translation merge. Now master
is borked.
We have the following options:
a) reset mas
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
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
33 matches
Mail list logo
