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
