Master and origin/master diverged

Master and origin/master diverged

[Hilco Wijbenga]

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.

Cheers,
Hilco

Re: Master and origin/master diverged

[Phil Hord]

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

If he used a gui, then I do not know how this option would be spelled,
but it may be called "force" or something else.

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 see the new commit SHA-1's on the lines that say "rebase:
<original commit message>"

But there are other ways to rewrite history, such as filter-branch.

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.

Phil

Re: Master and origin/master diverged

[Neal Kreitzinger]

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
(2) have your devs do git pull --ff-only

v/r,
neal

Re: Master and origin/master diverged

[Hilco Wijbenga]

Hi Phil,

On 22 June 2012 11:34, Phil Hord <phil.hord@gmail.com> wrote:
> 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.

My thoughts exactly.

> 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

Is that the same as

git push --force origin master

?

> If he used a gui, then I do not know how this option would be spelled,
> but it may be called "force" or something else.

AFAIK, he uses the CL for this. No GUI.

> 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

bb91ffa HEAD@{87 minutes ago}: checkout: moving from master to viz
bb91ffa HEAD@{88 minutes ago}: checkout: moving from viz to master
bb91ffa HEAD@{2 hours ago}: rebase finished: returning to refs/heads/viz
bb91ffa HEAD@{2 hours ago}: checkout: moving from viz to
bb91ffa3db35852bf6e9b15855421a1c5117b2f2^0
df9529a HEAD@{2 hours ago}: checkout: moving from master to viz
bb91ffa HEAD@{2 hours ago}: pull origin master: Fast-forward
cceee83 HEAD@{2 hours ago}: reset: moving to HEAD~23
df9529a HEAD@{2 hours ago}: checkout: moving from viz to master
df9529a HEAD@{2 hours ago}: checkout: moving from master to viz
df9529a HEAD@{6 hours ago}: checkout: moving from master to master
df9529a HEAD@{18 hours ago}: checkout: moving from master to master
df9529a HEAD@{18 hours ago}: checkout: moving from master to master
df9529a HEAD@{18 hours ago}: reset: moving to
df9529a4249b9de9cc1956283e5210b68acfe507
6633b41 HEAD@{18 hours ago}: pull origin master: Fast-forward
df9529a HEAD@{18 hours ago}: reset: moving to
df9529a4249b9de9cc1956283e5210b68acfe507
6633b41 HEAD@{18 hours ago}: checkout: moving from master to master
6633b41 HEAD@{18 hours ago}: pull origin master: Merge made by the
'recursive' strategy.
df9529a HEAD@{18 hours ago}: checkout: moving from master to master
df9529a HEAD@{18 hours ago}: rebase finished: returning to refs/heads/master
df9529a HEAD@{18 hours ago}: rebase: Fixed some visualization bug,
added resources for new spark visualization, deleted obsolete
resources
8944283 HEAD@{18 hours ago}: rebase: Clean up social-sticky-widget.
f9bc439 HEAD@{18 hours ago}: rebase: Resolve build error
14373e3 HEAD@{18 hours ago}: rebase: Changed social-widget
add-friend-button binding names.
abf30b9 HEAD@{18 hours ago}: rebase: Added social-sticky-widget to the
community lounge.
d01d4da HEAD@{18 hours ago}: rebase: Extend email support.
0a60fe0 HEAD@{18 hours ago}: rebase: Fixed asyncronous text and slowed
plane by 50%. (37.5% slower in total than original speed)
4777fdd HEAD@{18 hours ago}: rebase: Added social-sticky-widget.
e744734 HEAD@{18 hours ago}: rebase: Slowed plane speed down by 25%
and increased the font size.
52137b7 HEAD@{18 hours ago}: rebase: Fixed some graphical glitches
with the plane.
6e60b86 HEAD@{18 hours ago}: rebase: Updated the header and island to
only show nature path in demo.
23c8ccb HEAD@{18 hours ago}: rebase: Added plane to the header and
remove dock from production.
1107a7e HEAD@{18 hours ago}: rebase: Show completed Quests in Activity Summary.
260f8c5 HEAD@{18 hours ago}: rebase: Added dock to header and island swf.
0819d2c HEAD@{18 hours ago}: rebase: [DE575] Change friend bonus percentage.
17685ba HEAD@{18 hours ago}: rebase: Improve level queries.
35d69b4 HEAD@{18 hours ago}: rebase: Refactor Period.
9749d52 HEAD@{18 hours ago}: rebase: Make sure to use correct date range.
180b648 HEAD@{18 hours ago}: rebase: Added fix for images that were
not working in IE8 and cleaned up some commented code.
f94e317 HEAD@{18 hours ago}: checkout: moving from master to
f94e317e82ea939a931cdc691e267e7c64f4dc00^0
38f2bb6 HEAD@{19 hours ago}: commit: Fixed some visualization bug,
added resources for new spark visualization, deleted obsolete
resources
98f2a97 HEAD@{19 hours ago}: pull origin master: Fast-forward
b325a96 HEAD@{32 hours ago}: pull origin master: Fast-forward
f94e317 HEAD@{8 days ago}: checkout: moving from
f884b312dcdb247ddf7eaf7c11eb9ffaab034b40 to master
f884b31 HEAD@{8 days ago}: checkout: moving from master to
f884b312dcdb247ddf7eaf7c11eb9ffaab034b40^0
f94e317 HEAD@{8 days ago}: commit: Fixed visualizations scaling and
integration of nature visualization
5ab4887 HEAD@{8 days ago}: pull origin master: Fast-forward
564abdd HEAD@{9 days ago}: pull origin master: Fast-forward
283c602 HEAD@{11 days ago}: pull origin master: Fast-forward

I have left it in just to be complete but you should ignore everything
"2 hours ago" and more recent. (I fixed the problem and told him to
pull again; the advantage of a small team.)

This leads to 2 new questions.

1) What does "checkout: moving from master to master" mean?
2) I'm guessing the root of the problem is "pull origin master: Merge
made by the 'recursive' strategy."? I do not see a push anywhere,
though.

> You can see the new commit SHA-1's on the lines that say "rebase:
> <original commit message>"
>
> But there are other ways to rewrite history, such as filter-branch.

Given that *I* do not even really know about that, I doubt he would. :-)

> 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.

Cheers,
Hilco

Re: Master and origin/master diverged

[Hilco Wijbenga]

Hi Neal,

On 22 June 2012 12:01, Neal Kreitzinger <nkreitzinger@gmail.com> wrote:
> 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

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.

> (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. Actually, I guess what I really want is
something for git push, right?

Re: Master and origin/master diverged

[Phil Hord]

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.

Phil

Re: Master and origin/master diverged

[Hilco Wijbenga]

On 22 June 2012 15:10, Phil Hord <phil.hord@gmail.com> wrote:
> 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.

You mean which SHA-1s in the reflog? It's the ones listed as @{"18
hours ago"}: rebase: ... Sorry, I should have pointed that out.

The reflog lists the SHA-1s that the dev had and that were pushed to
origin/master (so B', C', and D' in my original description). The ones
that were on origin/master originally (and are/were on my local
master) are different (B, C, and D).

Re: Master and origin/master diverged

[Neal Kreitzinger]

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.
(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.

v/r,
neal

Re: Master and origin/master diverged

[Junio C Hamano]

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?

Re: Master and origin/master diverged

[Hilco Wijbenga]

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.

Re: Master and origin/master diverged

[Hilco Wijbenga]

On 22 June 2012 16:59, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

Re: Master and origin/master diverged

[Junio C Hamano]

Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:

> 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.

Well, there seem to be other Git hosting services with commercial
support and this might be a marketing opportunity for them ;-).

Re: Master and origin/master diverged

[Neal Kreitzinger]

On 6/25/2012 9:49 PM, Hilco Wijbenga wrote:
> 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?
I don't know about java, ruby, or JGit (yet).  I make hook updates easy 
with this alias:

get-hooks = !rm -f .git/hooks/pre-commit && git init 
--template=/opt/mydir/git-templates/dev/templates

I update the master copy of the pre-commit hook (in this case) in the 
template and then have the users run git get-hooks.  All my users are on 
the linux server.  Maybe this idea is helpful to you in some way.
>
>> (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.
>
You could create an alias 'git merger' and have them run that and it 
will do the --ff-only option.  Maybe post-merge hook and/or pre-commit 
hook.  I don't think --ff-only was part of your requirements so you can 
probably ignore this since I got off track by suggesting it.  I think 
your problem is history rewrites and not merge commits.  I think (1) 
--ff-only denies merge commits altogether, and (2) denyNonFastForwards 
allows merge commits but denies history rewrites so they (1 and 2) are 
not really the same though they both use the term 'fastforward' they 
have different definitions of what that means.  Someone please correct 
me if I'm wrong because this does seem a bit confusing now that I'm 
saying it out loud.

v/r,
neal