[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:58:25 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
- Does the following Python error in the musicxml tests ring a bell?, David Kastrup, 2020/03/02
- Re: Does the following Python error in the musicxml tests ring a bell?, Jonas Hahnfeld, 2020/03/02
- Re: Does the following Python error in the musicxml tests ring a bell?, David Kastrup, 2020/03/02
- Re: Does the following Python error in the musicxml tests ring a bell?, Jonas Hahnfeld, 2020/03/02
- Re: Does the following Python error in the musicxml tests ring a bell?, David Kastrup, 2020/03/02
- Re: Does the following Python error in the musicxml tests ring a bell?, Jonas Hahnfeld, 2020/03/03
- Re: Does the following Python error in the musicxml tests ring a bell?, David Kastrup, 2020/03/03
- Re: Does the following Python error in the musicxml tests ring a bell?, Jonas Hahnfeld, 2020/03/03
- Re: Does the following Python error in the musicxml tests ring a bell?, David Kastrup, 2020/03/03
- Re: Does the following Python error in the musicxml tests ring a bell?,
David Kastrup <=
- Re: Does the following Python error in the musicxml tests ring a bell?, Jonas Hahnfeld, 2020/03/03
- Re: Does the following Python error in the musicxml tests ring a bell?, David Kastrup, 2020/03/03
- Re: Does the following Python error in the musicxml tests ring a bell?, David Kastrup, 2020/03/03
- Re: Does the following Python error in the musicxml tests ring a bell?, Jonas Hahnfeld, 2020/03/03
- Re: Does the following Python error in the musicxml tests ring a bell?, David Kastrup, 2020/03/03
- translation updates in master (was: Re: Does the following Python error in the musicxml tests ring a bell?), Jonas Hahnfeld, 2020/03/03
- Re: translation updates in master, David Kastrup, 2020/03/03
- Re: translation updates in master, Jonas Hahnfeld, 2020/03/03
- Re: translation updates in master, David Kastrup, 2020/03/03
- Re: Does the following Python error in the musicxml tests ring a bell?, David Kastrup, 2020/03/02