[Biopython-dev] WARNING - I've just been rewriting history

[Eric Talevich]

On Thu, Jul 29, 2010 at 4:30 AM, Peter <biopython at maubp.freeserve.co.uk>wrote:

> Eric Talevich <eric.talevich at gmail.com> wrote:
> > Peter <biopython at maubp.freeserve.co.uk>wrote:
> >
> >> Hi all,
> >>
> >> If anyone has been trying to use the git repository in the last 12 hours
> or
> >> so, please note I have just re-written recent history. If in any doubt,
> do a
> >> fresh clone. According the github network no one else has committed
> >> anything recently, which is good.
> >>
> >> Re-writing history in git is possible but is generally considered a "bad
> >> thing" because someone might have already taken and worked from
> >> the "erased" changes. Hopefully I got away with it without messing
> >> anyone up...
> >>
> >
> > (emerges battered and bruised from the wreckage)
> >
>
> Ah - sorry Eric, but at least you sorted it out. Did you see the email
> first or discover something wrong the hard way?
>

The hard way. I had a small uncommitted change to PhyloXMLIO.py, and wanted
to apply it to the tip of the master branch. So I stashed my change, pulled
from upstream (just after the bad merge reversion), and popped the stash. My
change no longer applied cleanly, even though the history showed no new
commits affecting PhyloXMLIO.py. Suck.

Having burned myself with "git rebase -i" on my own github fork last summer,
I recognized the problem after you rewrote the upstream history: After
pulling from upstream (or origin), the local copy claims be several commits
ahead of the public branch it's supposed to mirror.


 > If anyone else besides be got hit by this, here's a summary of how to fix
> > your local repository without nuking all your local branches:
> >
> > # We're on the "master" branch, a clone of "upstream/master"
> > # This has an alternate history of biopython/biopython/master
> > # so "git pull upstream master" doesn't work anymore
> > git branch -m master borked
> > git checkout -b master upstream/master
> > git pull upstream master
> > # If everything looks OK...
> > git branch -d borked
> >
>
> i.e. Rename your local copy of the borked master, get a clean
> copy of the rewritten master, delete renamed borked master.
> Looks very sensible.
>

Yes. Plus: after pulling a clean copy of upstream/master, "git fetch
upstream" helps set things right again.


Laurent sent me this link off-list, it sounds very complicated:
>
> http://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt
>

This part looks key:

If at all possible, for example, if you find a problem that got merged
into the main tree, rather than revert the merge, try _really_ hard to
bisect the problem down into the branch you merged, and just fix it, or

try to revert the individual commit that caused it.



> Another suggestion for avoiding accidentally pushing weird changes to the
> > main repo: point your "master" branch at your personal fork on github
> > (normally called "origin"), rather than upstream. Then "git push" will do
> > the safe thing by default.
>
> i.e. Push to your personal github repository's master first? That way
> it won't harm the official repository?
>

Yeah, mainly for psychological reasons -- pushing to origin satisfies a
certain urge to publish new work, but typing "git push upstream master"
makes me think more carefully about whether a change set is ready for the
official repository.

-Eric