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
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 <imed...@grosshat.com> 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
>> 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
>> 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
>> 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
> --force`, since that overwrites the structure of the authoritative
> So, eanything you can do for avoiding merging without understanding would
> you to avoid such situations.