On Fri, Jun 22, 2012 at 1:53 PM, Hilco Wijbenga
<hilco.wijbenga@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html