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

[Peter]

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?

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

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

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

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

i.e. Push to your personal github repository's master first? That way
it won't harm the official repository?

Peter