Re: Please stop pushing to the translation branch until further notice

[David Kastrup]

Francisco Vila <address@hidden> writes:

> 2012/3/8 David Kastrup <address@hidden>:
>> The situation should now be under control again.  The translation branch
>> has been merged with a helper branch that should bring in all the
>> changes from commits that the merge history suggests to be present.
>
> Thank you, David. I apologize. I feel bad for your (and other's) loss
> of valuable time.
> Yes, I tried to be clever, autonomous, do not cause troubles to
> others, etc.

Well, git is powerful.  And yes: the translation work is something that
works "behind the scenes" to an astonishing degree and for me means
stuff that I don't need to worry about since it will "somehow happen"
(TM).  The downside to this magic is that you are working a lot on your
own, and figuring stuff on your own, and you are the one in the
translation team doing the "ugly" things like branch merges.

> I was not clever enough in the first place, judging from the
> results. I obviously did not check all that needed to be checked.  The
> checklist size is ever growing.

And partly because the translation team is operating rather silently, I
have my doubts that we have really good instructions for them in CG or
elsewhere.

> To avoid this in the future, I will not do push or merge when
> something looks suspicious.  That's what I have done in the past few
> months, when -- besides well-known pack/dist problems -- all has gone
> more or less smoothly, but this time I failed rather catastrophically.

Well, let's see it realistically.  The mainline has seen one really bad
commit (with diverging history and work tree), and one commit faking
history to bring both into line again.  We'll need to reverify every
issue after 2.15.30 to be on the safe side, but chances are pretty good
that there will be only few to no permanent problems.  Once we have
merged master back into the translation branch, all of the commits and
fake commits will be present in both branches.  That makes it likely
that any reverts we need to be doing on material in the affected commits
will actually work.  Development was locked up for a day, tension was
there for a day, I put in a day's work, the sidebranch history is messed
up for a while but now in synch again.  Translators will have to check
that my fixup work did not cause work of them to get lost.

And going by my usual standards, I did not even blow up.  It was bad
coincidence that this happened just when I had lots of other stuff to
do.

> This could easily be the worst disaster since Erik Sandberg lost his
> laptop.

No.  This is git.  One could have just reverted the merge commit into
the mainline, reset the translation branch to master, and cherrypicked
every change done in the translation branch since the last merge to
master manually into a new translation branch.  Every translator would
have had to reset his repository and work.  Maybe that would have been
the saner way to proceed, but it would have made a new mess in case some
translator would not have reset his branch.

I chose a fix that required no reset of either master or translation.
That was more complex for me, but it will hopefully be less complex to
others.  Perhaps I was being too clever here.  Which is a problem when
working with git.  Ok, probably I _was_ being too clever.  Easy to make
this mistake with git.  The solution with a full revert and a junking
and recreation of the translation branch would not have required the bug
squad to verify everything after 2.15.30 again.

Tough.  It was the best I was able to come up with on short notice.  On
the other hand, there were merges _from_ master into the translation
branch in the mean time, and that would have complicated that approach
as well.

> Thankfully we had backups, Erik had not.

He should have taken a lesson from Linux Torvalds (who does not bother
with backups either I seem to remember).  Just make sure that your
important work is spread across enough repositories.

To put some cosmic balance to it: last fall I had a fatal headcrash on
my previous computer.  Disk dead 100%, backups about 2 years old (the
ones I could access at first were actually more like 8 years).  When I
reinstalled a new system, I did not reinstall my Usenet access, and
passwords to a number of web forums.  Basically I took the opportunity
to let a lot of my internet identity die.

That was the point of time when my work on LilyPond seriously commenced.

In any case: I think you should merge (merge!) more often, master to
translation, translation to staging.  It does not make all that much
sense if translations come 2 versions later into master than they have
been written.  And when things go wrong, they go wrong in smaller
portions, and fewer stuff needs to get verified after cleaning up.

When you feel insecure about pushing something to staging, you can
always try pushing to some branch like

git push origin HEAD:refs/heads/dev/staging-test

instead and ask for opinions.  I don't think that we have much of a
chance teaching Patchy to figure out _structural_ inconsistencies in
merge commits.

-- 
David Kastrup