Re: Bad translation merge

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> Hi,
>
> one question: we can checkout a commit before merge commit and thus
> "fix" master?  So, the main problem is how to fix translation
> properly?

We can't "fix" master that easily.  You'll get a nice working tree in
that manner, but you can't push that to master.  And the next time you
merge translations into master, they will break everything again.

I've created a rebased branch containing all the commits that were
dropped in the faulty merge, and merged that into translation (the
result is at dev/translation).  I then merged that back into master (of
course, having to undo Francisco's "conflict resolution", partly
manually resolved merge conflicts, partly reremoving stuff that was
removed in master commits and resuscitated in manual merge resolution).

The result of that is in /dev/staging.

Now I don't have sufficient resources to continue reasonably fast.
Somebody needs to do make test-baseline on the last commit before the
merge (should be origin~1), and then a make check on the stuff in
/dev/staging.  This should turn up no differences (except for those
caused by translation).  If that's ok, we can push this to staging
proper and see how Patchy fares with it.

And somebody should check the diff between dev/translation and
lilypond/translation and make sure that those differences are not
undoing any work by the translators.  They shouldn't, but I am not
totally sure.  I hope I don't cause extra work here.  There seem to be a
lot of changes in "committish" info.

-- 
David Kastrup