Re: Please stop pushing to the translation branch until further notice
2012/3/8 David Kastrup d...@gnu.org: 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. 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. 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. This could easily be the worst disaster since Erik Sandberg lost his laptop. Thankfully we had backups, Erik had not. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please stop pushing to the translation branch until further notice
Hello, On 8 March 2012 11:08, David Kastrup d...@gnu.org wrote: ... 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. Is this something 'we' could add easily to patchy? Then I could be doing that as part of what I am doing already? -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please stop pushing to the translation branch until further notice
James pkx1...@gmail.com writes: On 8 March 2012 11:08, David Kastrup d...@gnu.org wrote: ... 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. Is this something 'we' could add easily to patchy? Then I could be doing that as part of what I am doing already? I would not want that. I have made it a point to make sure that Patchy does not ever do anything except fast forwarding. Merges are a potentially complex operation and should be done under human control. Only a human will know when a merge has been straightforward or not, and how much attention to spend on its result. Most merges will be a thing done in a minute without thinking, but there may be some that require more attention. And a tool like Patchy would not know when. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please stop pushing to the translation branch until further notice
David Kastrup d...@gnu.org writes: We currently have the situation that bad commits on the translation branch have caused a loss of work in our main repository. While I am trying to sort out the damage, it is not helpful if you keep pushing new material to the translation branch. Please refrain from doing so for now. It makes things even harder to fix. Thanks 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. Please check that git diff 32b9cd030a1..569714401 (the merge commit resulting in the current translation branch state) is legit and does not lose any of your work. This should bring the translation branch to a state of master located somewhere before 2.15.31. _After_ (!!!) you have made sure that none of your work has been lost here, you can merge from origin into the translation branch, bringing it to a state post 2.15.32. Just to be on the safe side, I would prefer doing the merge of the translation branch back to staging myself next. Once you have checked that the recent fixes have not caused any of your work to get lost and the criss-cross merge has been done, you can continue committing to the translation branch. I apologize for the inconvenience. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please stop pushing to the translation branch until further notice
Once you have checked that the recent fixes have not caused any of your work to get lost and the criss-cross merge has been done, you can continue committing to the translation branch. I apologize for the inconvenience. Thanks a lot for fixing this. Do you recommend a modification of the current workflow to avoid this problem in the future? It probably doesn't affect me since I don't do branch merges, but just to be sure... Usually I follow your advice sent some time ago to the list: git fetch (to be sure you have the current version of staging) git checkout origin/staging ... commit your simple change ... git push origin HEAD:staging Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please stop pushing to the translation branch until further notice
Werner LEMBERG w...@gnu.org writes: Once you have checked that the recent fixes have not caused any of your work to get lost and the criss-cross merge has been done, you can continue committing to the translation branch. I apologize for the inconvenience. Thanks a lot for fixing this. Do you recommend a modification of the current workflow to avoid this problem in the future? It probably doesn't affect me since I don't do branch merges, but just to be sure... Usually I follow your advice sent some time ago to the list: git fetch (to be sure you have the current version of staging) git checkout origin/staging ... commit your simple change ... git push origin HEAD:staging It's totally fine. The problem was caused by _not_ adhering to procedures and then digging one self further in instead of resetting and restarting or asking for advice. One problem was rebasing instead of merging between the translation and master branches. That caused some nuisances by ruining the history (changes appearing on more than one branch, consequently at least one revert that I did, \layout-from, had to be redone manually several times). The real problem was that ominous merge (probably with a merge strategy of theirs or ours) that did not actually merge but copy. And the damage that this caused was rather large because it has been a really long time since the translation branch had been merged into staging last before that merge, and since it was a really long time afterwards that the merge into the main line happened. So a lot of history needed fixing. A systematic problem was to check for correctness of the merge by making test and building docs: those won't notice if you accidentally rewind the state of master a few weeks, because we make it a point to have every commit on master pass regression tests and doc builds. If you want to make sure there is not something fishy with a merge, you need to look at the diffs in relation to the parents, at least the diffstat showing which files changed how much. I think the main thing is don't be clever around git. Which I do not heed entirely myself, obviously. But I do hard resets to the state of 15 minutes ago when something does not look good. Restarting from scratch in your local repository is easy with git. Being clever has no place on long-running public branches. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
