On Wed, 21 Nov 2012, Brian Kotek wrote:
One of the developers (new to Git) did something bizarre like merge an old branch into a new one and then push it. As a result, a lot of files were deleted or changed (back to older versions). No one initially noticed (we have a CI server but it only runs at specific times because the builds take a while). Other folks pulled and some additional commits were even pushed to remote on top of that bad merge. So, "fixing" the remote branch was pretty easy (I did a rebase and skipped the bad commits), then did a forced push to get remote in sync with my rebased version. Others could pull just fine. However (and you may see what's coming), when they did a push, the bad merge was pushed back to remote because others now had it in their local repos. We were able to finally deal with it by having the other folks do a hard reset so their local repo matched the "good" head revision on remote. What I'd like to ask is: Did I handle this the right way? Is there a better way to deal with this sort of situation? I realize that one really shouldn't get into this situation in the first place, but if it nonetheless happens, how do you recover? Any advice appreciated.
A first alternative might be not using a Merge Workflow. It produces a bunch of errors when you have many committers or they are less-trained committers. A second step might be avoiding the default configuration that allows `git push --force`, since that overwrites the structure of the authoritative repository. So, eanything you can do for avoiding merging without understanding would help you to avoid such situations. iñ
Thanks, Brian --
--
