Apologies in advance, I know bumping isn't good form. But since many folks may have been out last Wed. due to the holiday, I wanted to at least make sure this wasn't missed. If anyone has anything to add, I'd appreciate the input.
Thanks, Brian On Wed, Nov 21, 2012 at 6:45 PM, Brian Kotek <[email protected]> wrote: > Thanks, Inigo. I guess the real question I have is less about ways to > prevent this from happening, and more about what to do if it DOES happen. > Prevention is great, and this is the first time something like this has > happened to us. But it brought into focus just how easy it actually is for > someone to unwittingly create major problems that were difficult to > resolve. So I'd really like to hear from folks who have also seen this > happen and can tell me either "yes, what you did is really the only way to > resolve this" or "no, what you should have done to resolve it was X, Y, and > Z". > > So thanks again. But do you (or anyone else) have thoughts on how you deal > with something like this if does happen, despite preventative measures? > > > On Wed, Nov 21, 2012 at 6:09 PM, Inigo Medina <[email protected]>wrote: > >> >> 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 >>> >>> >>> -- >>> >>> >>> >>> >> -- >> >> >> > --
