[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does the following Python error in the musicxml tests ring a bell?

From: David Kastrup
Subject: Re: Does the following Python error in the musicxml tests ring a bell?
Date: Tue, 03 Mar 2020 11:23:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Jonas Hahnfeld <address@hidden> writes:

> Am Dienstag, den 03.03.2020, 11:05 +0100 schrieb David Kastrup:

>> > Only for the final outcome. 'git bisect' will still walk into (most of)
>> > stable/2.20 which is likely not what we want it to do. I'll try to have
>> > a look later today if we can do better.
>> Darn.  So we'd need to get rid of the history, right?
> Yes. Ideally we would cherry-pick only the translation updates from
> stable/2.20.

Sounds more like we are interested in turning the merge commit into the
application of a diff.  Namely committing parenticide on its source.

> Basically all commits that touched only files in Documentation/[lang]
> between origin/translations-staging and the merge base with
> origin/master. I think this should be doable automatically.

Nope, lots of conflicts.  Typically because of convert-ly runs in the
master branch, or because of changes that were done (or had to be done
to keep stuff working) across all translations in master.

> I'll give it a try later on.

Maybe git rerere (based on what we have now already) and/or git
psykorebase can help with your idea?  No promise, just throwing out
tools I have occasionally read the documentation of but have not
successfully used myself.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]