Master and origin/master diverged

> One of my developers managed to push something that somehow "diverged"
> origin/master from everyone else's local master.
>
> A --> B --> C --> D (everybody's local master)
> |
> \--> B' --> C' --> D' --> E (origin/master)
>
> (i.e., A is the commit where things diverged; everyone's local master
> points to D but the new commit (E) that was pushed to origin/master
> uses different SHA1s for B, C, and D). I hope I explained it clearly
> enough.
>
> Now running git pull creates a merge commit joining D and E.
>
> When I asked the developer what he had done he told me everything had
> looked normal. No Git warnings, nothing strange in gitk (i.e. normal
> linear history). So I do not understand what went wrong.
>
> Does anyone have any idea as to what might have happened? Perhaps if I
> understand how this happened I might be able to prevent it from
> happening again.

> On Fri, Jun 22, 2012 at 1:53 PM, Hilco Wijbenga
> <hilco.wijbenga@gmail.com> wrote:
>> One of my developers managed to push something that somehow "diverged"
>> origin/master from everyone else's local master.
>>
>> A --> B --> C --> D (everybody's local master)
>> |
>> \--> B' --> C' --> D' --> E (origin/master)
>>
>> (i.e., A is the commit where things diverged; everyone's local master
>> points to D but the new commit (E) that was pushed to origin/master
>> uses different SHA1s for B, C, and D). I hope I explained it clearly
>> enough.
>>
>> Now running git pull creates a merge commit joining D and E.
>>
>> When I asked the developer what he had done he told me everything had
>> looked normal. No Git warnings, nothing strange in gitk (i.e. normal
>> linear history). So I do not understand what went wrong.
>>
>> Does anyone have any idea as to what might have happened? Perhaps if I
>> understand how this happened I might be able to prevent it from
>> happening again.
>
> There are a number of ways this can happen, but they all involve
> rewriting history.  Usually that is something your developer would be
> aware of doing.  It does not usually happen by mistake.

> Also, in order to push the new E commit, the developer would have to
> "force" the push by placing a "+" in front of the references, like
> this:
>
>  git push origin +master:master

> You can look at the reflog on the developer's machine to determine
> where the new commits came from.  For example, here are some commits I
> rebased a few weeks ago in a repository on my machine:
>
> $ git reflog --relative-date
> c93b31b HEAD@{6 weeks ago}: checkout: moving from mine to c93b31b
> 93a357f HEAD@{6 weeks ago}: rebase finished: returning to refs/heads/mine
> 93a357f HEAD@{6 weeks ago}: rebase: Add a makefile to help me remember
> how to make
> f804993 HEAD@{6 weeks ago}: rebase: Allow working in multiple branches
> c93b31b HEAD@{6 weeks ago}: rebase: Update Gerrit 2.4 ReleaseNotes
> 5cac09e HEAD@{6 weeks ago}: rebase: Gerrit 2.4 ReleaseNotes
> f41a9b4 HEAD@{6 weeks ago}: checkout: moving from mine to
> f41a9b447304733a1784ece373723f8622c8dbad^0
> 879e5d9 HEAD@{6 weeks ago}: rebase finished: returning to refs/heads/mine
> 879e5d9 HEAD@{6 weeks ago}: rebase: Add a makefile to help me remember
> how to make
> 35d7a48 HEAD@{6 weeks ago}: rebase: Allow working in multiple branches
> c7a845a HEAD@{6 weeks ago}: rebase: Update Gerrit 2.4 ReleaseNotes
> 7b51315 HEAD@{6 weeks ago}: rebase: Gerrit 2.4 ReleaseNotes
> d6799b1 HEAD@{6 weeks ago}: checkout: moving from mine to
> d6799b1d40ffc5412e4174fd95bd5fb412781537^0
> d9bb39b HEAD@{6 weeks ago}: checkout: moving from
> d6799b1d40ffc5412e4174fd95bd5fb412781537 to mine
> d6799b1 HEAD@{6 weeks ago}: checkout: moving from mine to origin/master
> d9bb39b HEAD@{6 weeks ago}: commit (amend): Add a makefile to help me
> remember how to make
> 62097f8 HEAD@{6 weeks ago}: commit: Add a makefile to help me remember
> how to make
> dfa61e4 HEAD@{6 weeks ago}: checkout: moving from
> dfa61e465bcb27f5698c48d1ec9d32e8fd62c604 to mine

>> You can also compare the commits to see what the differences are.
>> This may trigger  the developer's memory about how it might have
>> happened.
>
> The only differences seem to be the SHA-1s.

> On Fri, Jun 22, 2012 at 4:14 PM, Hilco Wijbenga
> <hilco.wijbenga@gmail.com> wrote:
>>> You can also compare the commits to see what the differences are.
>>> This may trigger  the developer's memory about how it might have
>>> happened.
>>
>> The only differences seem to be the SHA-1s.
>
> Can you tell me which SHA-1s they are?  It will be easier for me to
> guess at the reflog contents, then.

> Hi all,
>
> One of my developers managed to push something that somehow "diverged"
> origin/master from everyone else's local master.
>
> A --> B --> C --> D (everybody's local master)
> |
> \--> B' --> C' --> D' --> E (origin/master)
>
> (i.e., A is the commit where things diverged; everyone's local master
> points to D but the new commit (E) that was pushed to origin/master
> uses different SHA1s for B, C, and D). I hope I explained it clearly
> enough.
>
> Now running git pull creates a merge commit joining D and E.
>
> When I asked the developer what he had done he told me everything had
> looked normal. No Git warnings, nothing strange in gitk (i.e. normal
> linear history). So I do not understand what went wrong.
>
> Does anyone have any idea as to what might have happened? Perhaps if I
> understand how this happened I might be able to prevent it from
> happening again.
>

> On 6/22/2012 12:53 PM, Hilco Wijbenga wrote:
>>
>> Hi all,
>>
>> One of my developers managed to push something that somehow "diverged"
>> origin/master from everyone else's local master.
>>
>> A --> B --> C --> D (everybody's local master)
>> |
>> \--> B' --> C' --> D' --> E (origin/master)
>>
>> (i.e., A is the commit where things diverged; everyone's local master
>> points to D but the new commit (E) that was pushed to origin/master
>> uses different SHA1s for B, C, and D). I hope I explained it clearly
>> enough.
>>
>> Now running git pull creates a merge commit joining D and E.
>>
>> When I asked the developer what he had done he told me everything had
>> looked normal. No Git warnings, nothing strange in gitk (i.e. normal
>> linear history). So I do not understand what went wrong.
>>
>> Does anyone have any idea as to what might have happened? Perhaps if I
>> understand how this happened I might be able to prevent it from
>> happening again.
>>
> Some ways you can prevent it from happening again:
> (1) setting your canonical repo config to deny non-ff, and deny deletes:
> [receive]
>        denyDeletes = true
>        denyNonFastforwards = true

>
> On 22 June 2012 12:01, Neal Kreitzinger <nkreitzinger@gmail.com> wrote:
>> On 6/22/2012 12:53 PM, Hilco Wijbenga wrote:
>>>
>>> One of my developers managed to push something that somehow "diverged"
>>> origin/master from everyone else's local master.
>>>
>>> A --> B --> C --> D (everybody's local master)
>>> |
>>> \--> B' --> C' --> D' --> E (origin/master)
>>>
>>> (i.e., A is the commit where things diverged; everyone's local master
>>> points to D but the new commit (E) that was pushed to origin/master
>>> uses different SHA1s for B, C, and D)...
>>>
>>> Now running git pull creates a merge commit joining D and E.
>>>
>>> ...Does anyone have any idea as to what might have happened? Perhaps if I
>>> understand how this happened I might be able to prevent it from
>>> happening again.
>>>
>> Some ways you can prevent it from happening again:
>
>> (2) have your devs do git pull --ff-only
>
> Is this something that can be set in git config? I looked but didn't
> see anything obvious.

> On 6/22/2012 3:18 PM, Hilco Wijbenga wrote:
>>
>>
>> On 22 June 2012 12:01, Neal Kreitzinger <nkreitzinger@gmail.com> wrote:
>>>
>>> On 6/22/2012 12:53 PM, Hilco Wijbenga wrote:
>>>>
>>>>
>>>> One of my developers managed to push something that somehow "diverged"
>>>> origin/master from everyone else's local master.
>>>>
>>>> A --> B --> C --> D (everybody's local master)
>>>> |
>>>> \--> B' --> C' --> D' --> E (origin/master)
>>>>
>>>> (i.e., A is the commit where things diverged; everyone's local master
>>>> points to D but the new commit (E) that was pushed to origin/master
>>>> uses different SHA1s for B, C, and D)...
>>>>
>>>>
>>>> Now running git pull creates a merge commit joining D and E.
>>>>
>>>> ...Does anyone have any idea as to what might have happened? Perhaps if
>>>> I
>>>>
>>>> understand how this happened I might be able to prevent it from
>>>> happening again.
>>>>
>>> Some ways you can prevent it from happening again:
>>
>>
>>> (2) have your devs do git pull --ff-only
>>
>>
>> Is this something that can be set in git config? I looked but didn't
>> see anything obvious.
>
>
> OTTOMH, you could change the git fetch config for master and take away the
> leading '+' sign which would not allow non-fastforward fetches of master.
>  That in turn would prevent merging such a non-ff remote tracking branch of
> master into your branch master.
>
>
> Actually, I guess what I really want is
>>
>> something for git push, right?
>>
> Some ways to do it:
> (1) I think you could have rebase and commit hooks locally that prevent
> someone from rewriting history on master.  That in turn would prevent
> someone from pushing a rewritten history.

> On 22 June 2012 16:47, Neal Kreitzinger <nkreitzinger@gmail.com> wrote:
>> On 6/22/2012 3:18 PM, Hilco Wijbenga wrote:
>>>
>>> On 22 June 2012 12:01, Neal Kreitzinger <nkreitzinger@gmail.com> wrote:
>>>> On 6/22/2012 12:53 PM, Hilco Wijbenga wrote:
>>>>>
>>>>> One of my developers managed to push something that somehow "diverged"
>>>>> origin/master from everyone else's local master.
>>>>>
>>>>> A --> B --> C --> D (everybody's local master)
>>>>> |
>>>>> \--> B' --> C' --> D' --> E (origin/master)
>>>>>
>>>>> (i.e., A is the commit where things diverged; everyone's local master
>>>>> points to D but the new commit (E) that was pushed to origin/master
>>>>> uses different SHA1s for B, C, and D)...
>>>>>
>>>>>
>>>>> Now running git pull creates a merge commit joining D and E.
>>>>>
>>>>> ...Does anyone have any idea as to what might have happened? Perhaps if
>>>>> I
>>>>>
>>>>> understand how this happened I might be able to prevent it from
>>>>> happening again.
>>>>>
>>>> Some ways you can prevent it from happening again:
>>>
>>>> (2) have your devs do git pull --ff-only
>>>
>>> Is this something that can be set in git config? I looked but didn't
>>> see anything obvious.
>>
>> OTTOMH, you could change the git fetch config for master and take away the
>> leading '+' sign which would not allow non-fastforward fetches of master.
>>   That in turn would prevent merging such a non-ff remote tracking branch of
>> master into your branch master.
>>
>>
>> Actually, I guess what I really want is
>>> something for git push, right?
>>>
>> Some ways to do it:
>> (1) I think you could have rebase and commit hooks locally that prevent
>> someone from rewriting history on master.  That in turn would prevent
>> someone from pushing a rewritten history.
> Yes, I have been thinking about that.
>
> How does one create "portable" hooks? I have to deal with GNU/Linux,
> OS X, and MS Windows. We all have Java installed so I first thought of
> using JGit but I am not clear on how well JGit supports using it in a
> hooks. Should I make Ruby a required part of the dev environment and
> use Ruby hooks?

>
>> (2) When merging topic branches to master use git merge --ff-only.  Then
>> when you push it to remote master you know it's a fastforward and not a
>> history rewrite.
> Given how hard it is to teach devs to only push fast-forward merges, I
> am not sure how well this would work.
>

>> Some ways you can prevent it from happening again:
>> (1) setting your canonical repo config to deny non-ff, and deny deletes:
>> [receive]
>>        denyDeletes = true
>>        denyNonFastforwards = true
>
> I would *really* like to do that but I need access to the server for
> that, right? Unfortunately, we use Unfuddle and that means no such
> access. So no server config changes and no Git hooks.

> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>
>>> Some ways you can prevent it from happening again:
>>> (1) setting your canonical repo config to deny non-ff, and deny deletes:
>>> [receive]
>>>        denyDeletes = true
>>>        denyNonFastforwards = true
>>
>> I would *really* like to do that but I need access to the server for
>> that, right? Unfortunately, we use Unfuddle and that means no such
>> access. So no server config changes and no Git hooks.
>
> receive.denyNonFastforwards is a reasonable thing to ask for
> projects with a shared repository workflow, so I suspect hosting
> service providers may want to race adding support for it to win
> customers.  Have you asked them?

> I agree and I was thinking of doing exactly that. So after your
> friendly nudge I sent them an email.
>
> The first (very prompt) reply said they didn't support "custom hooks".
> When I explained that I was not asking for a custom hook but that I
> simply wanted a Git setting changed, I was informed (again, very
> promptly)  that that was quite impossible. :-(
>
> In my opinion, it should be fairly simple for them to create a web UI
> to set Git config settings (I can understand they do not want to do it
> manually) but they do not seem very interested. A bit surprising and
> certainly very disappointing.