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 <brian...@gmail.com> 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 <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
>>> 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
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>> --
>>
>>
>>
>

-- 


Reply via email to