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

[Jonas Hahnfeld]

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?

Jonas

signature.asc
Description: This is a digitally signed message part