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

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Dienstag, den 03.03.2020, 11:13 +0100 schrieb Jonas Hahnfeld:
>> Am Dienstag, den 03.03.2020, 11:05 +0100 schrieb David Kastrup:
>> > Jonas Hahnfeld <
>> > address@hidden
>> > 
>> > > writes:
>> > > Am Montag, den 02.03.2020, 21:40 +0100 schrieb David Kastrup:
>> > > > Jonas Hahnfeld <
>> > > > address@hidden
>> > > > 
>> > > > 
>> > > > > writes:
>> > > > > Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup:
>> > > > > > dev/translation-merge
>> > > > > > 
>> > > > > > Fails at make test (at least on my system).
>> > > > > 
>> > > > > Ah, the merge re-instantiated some code for Python 2. The following
>> > > > > diff fixes 'make test' for me:
>> > > > 
>> > > > [...]
>> > > > 
>> > > > > But very please DO NOT MERGE your branch dev/translation-merge into
>> > > > > master: It will pull in most of the cherry-picked commits from
>> > > > > stable/2.20 which will probably render 'git bisect' useless. Not sure
>> > > > > if that was done for previous releases but it certainly doesn't seem
>> > > > > right for that many commits in stable/2.20 that are not in master.
>> > > > 
>> > > > This is a travesty.  I was sure that I checked out every...  every 
>> > > > merge
>> > > > conflict outside of Documentation/?? ...
>> > > > 
>> > > > Darn.  Those files weren't conflicting.
>> > > > 
>> > > > Good that we talked about it.  I'll paste over everything else outside
>> > > > of Documentation/??/ that differs from master still.
>> > > > 
>> > > > If the merge commit touches nothing other than that, we should be fine,
>> > > > right?
>> > > 
>> > > 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. 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.
>> I'll give it a try later on.
>
>  $ base=$(git merge-base origin/master origin/translation-staging)
>  $ git checkout -b translation-picking $base
>  $ commits=$(git log --oneline --no-merges --invert-grep
> --grep="cherry picked from" --grep="convert-ly" --pretty=format:%H
> --reverse origin/translation-staging...$base --
> Documentation/{ca,cs,de,es,fr,hu,it,ja,nl,po,pt,zh})
>  $ git cherry-pick -x $commits
>
> This gives me 6 rather small merge conflicts that I could easily
> handle, plus skipping 4681e271ab and 41a35ee2dd (that are in master
> anyhow). The result is at dev/translation-picking.
> Now when merging this into master I get a whole set of conflicts. I
> guess you saw the same? Any trick how to handle this?

Four hours of work.  But why even bother?  Checkout my version, do a
reset --soft to your version and commit -C HEAD to your version.

The history is yours, the tree is mine.

-- 
David Kastrup