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

[David Kastrup]

David Kastrup <address@hidden> writes:

> 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.

Or what if we just recklessly do

git reset --soft 69cdac6f8f
git commit -C cd35097da04f3828f36410e668cda1df6bc6d524

on the current translation branch?

The disadvantage I see with that is that, well, we lose the history.  We
probably would want to keep a reference to it around.  And it would make
git-blame on the translations into a nightmare.

I frankly have no good idea how you'd keep git-blame working while
git-bisect would not look at the ping-ponged translation/stable commits.

-- 
David Kastrup