[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: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

reply via email to

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