David Kastrup <[email protected]> writes: > The "mess" that Mike left is typical for large scale branches, and it > could be fast-forwarded from staging to master (including the mess's > structure) once Mike put it to staging, so Patchy had no reason trying > to reorganize the material. > > Patchy does _not_, _never ever_ reorganize anything when moving it from > staging to master. > > So committers should check the version of staging they are going to > push _before_ pushing it.
I could teach Patchy to not proceed whenever the moved material would include a merge commit, or a merge commit with standard merge message (meaning that you would have to do an explicit merge with a manually written merge message if you really wanted to have a merge commit move). That's all rather hand-wavy and fragile. The #1 sanity rule, of course is: CHECK WHAT YOU ARE PUSHING!!!!! git log --graph --decorate staging or so should give you a good idea what you are doing. And you do that _right_ before you push, _without_ any intervening pulls or anything else. Patchy does not check the internal structure of staging. It just checks that it is a straight descendent of master. git is pretty good with dealing with criss-cross merges (as long as nobody bypassed its knowledge of things, like by working with non-git patches from Rietveld), so it is likely even possible to revert one of the "duplicate" commits and get the correct result. But it makes the history quite harder to read and work with. So again: CHECK WHAT YOU ARE PUSHING!!!!! -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
