Git push changes made via filter-branch

Question

I cut the history of my master branch into an old_stuff branch, via the advice of this Q&A: How do I remove the old history from a git repository? . To save you a click-through, the process involves grafting the last commit of master to the root commit, effectively giving it no parent, then using git filter-branch to make that change permanent. My local repository is now how it should be, with a short master branch and a long history branch.

But if I git clone the repository, that commit that shouldn't have a parent has the same parent as before. When I do git push -f origin master, I wind up with a master branch with the newly created commit at its head, but with a parent of the prior commit to master. So now I have a long old_stuff branch and a master branch that is as long plus one commit. If it's relevant, the remote is on Github.

How do I tell the remote repository and other copies to revise the parent for the new commit?

PS: I've read the warnings about how changing the history at a shared repository breaks other people's copies. I know the names of the people involved and can ask them to accommodate, so I'm comfortable revising the branch history in this current case.

Answer 1

How do I tell the remote repository and other copies to revise the parent for the new commit?

You.... can't do that. If you change the parent of a commit, you're changing that commit, with everything that goes along with that (new sha1, etc). It might be more helpful to think of the "parent" as a "child", in terms of which way the pointers are pointing.

It sounds like you're trying to get your history down to one commit. If that's the case, then checkout (heh) git checkout --orphan. Once you've done that, it's a matter of pointing your master at it (git reset --hard <new orphan branch> while on master) and a forced push to origin.

Any work your compatriots have done will need to be replayed on top of this new master; cherry-pick will help there.