Graham Percival <gra...@percival-music.ca> writes: > We've got a mess in master now, starting with > 0f68a5a1b6f789c2a0ec0e4584a3495832a3b6d7 > > I noticed the problem before Patchy ran, but I assumed that the > merge --ff-only would reject the mess. Unfortunately it didn't, > so we now have a span of a few commits that will fail to compile, > as well as some duplicated commits. > > Mike, what did you do when you pushed your addition of > 5657e399609abfa2436aeec74e2498d16219e813 > ? I want to find out if there were any warnings that you skipped > over, or if Patchy needs some extra checks, or what. The whole > point of Patchy is that we should avoid this situation. > > I have vague suspicions about git pull -r vs. git pull; we used to > be told to always use git pull -r but it appears that David favors > plain git pull (or rather: a combination of git fetch and > something else).
If Mike had used git pull -r instead of a plain pull without rebase, this "mess" would not have happened. For small-scale changes, git pull -r is pretty much the right idea before pushing to staging. For synchronizing large branches (like staging with master) it is quite a bad idea. > If that's the cause of this problem, let's get the CG cleared up. In general, you want to rebase to staging before pushing to staging. Always. Since pulling tends to do things I don't want (too much cleverness involved), I usually avoid it. In any case, if a pull tells you that it _merged_ something, don't further proceed blindly. Check what you are doing. 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. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
