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

[Eric Talevich]

On Tue, Jul 27, 2010 at 6:28 AM, 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)

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


Note that this only recreates a fresh copy of Biopython's official master
branch; if you've made commits on top of the borked history, or merged it
into other branches, you should probably just make a fresh clone and export
your local branches as patch sets.


What I did and why: One of our team made a bad merge, and pushed it to
> the master. If this had been spotted BEFORE being made public a local
> revert could have been done. The standard procedure here is to do a
> merge revert, but unfortunately it seems they reverted to the wrong branch
> (merge reverts can be done back to either of the two parents). At this
> point
> we had two unwanted commits, and the best way to fix this wasn't clear
> [at least not to us - has anyone got advice here for future reference?].
>

As usual in git, there's probably a way to do this, but I sure don't know
what it is.



> If you are not confident about merging branches, perhaps sending a
> merge pull request might be safer - get someone else to go it ;)
> Would anyone other than me feel happy handling merge requests?
>

Starting a month or so from now, I'd be willing to take a crack at 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.

Regards,
Eric