Francisco Vila <[email protected]> writes: > 2012/3/8 David Kastrup <[email protected]>: >> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
