Translated to git terminology, we want to force the master branch of the mathnet remote repository to the parent of dd61ab32: 1:

Let's say we have a remote mathnet with branch master that currently points to commit dd61ab32. Case 1: Delete the last commitĭeleting the last commit is the easiest case. Others prefer doing such rewritings themselves. There are maintainers that do not allow any rewriting in general and block any non-fastforward pushes. In opensource projects, always contact the repository maintainer first before doing any history rewriting. to fetch some pull requests on top of the old history. For example you can still cherry-pick commits between the histories, e.g. Yes, you should avoid rewriting history which already passed into other forks if possible, but the world does not end if you do nevertheless. I recently also had to rewrite a large git repository to get rid of some corruption in an early commit that started causing more and more problems. I usually also do a lot of very heavy history rewriting when converting some repository from Subversion or Mercurial over to Git, be it to enforce internal LF line endings, fixing committer names and email addresses or to completely delete some large folders from all revisions. Be it because of leaked sensitive information, to get rid of some very large files that should not have been there in the first place, or just because you want a clean history (I certainly do). However, sometimes you do want to rewrite the history. If they have local changes, they have to do some work to get in sync again work which requires a bit more knowledge on how Git works to do it properly. People cannot just pull your rewritten history as usual. People generally avoid history rewiriting, for a good reason: it will fundamentally diverge your repository from anyone who cloned or forked it. Just like above, the bad commit remains there, but it no longer affects the the current master and any future commits on top of it. Reverting a commit means to create a new commit that undoes all changes that were made in the bad commit.

Instead of going through all the changes manually, you can simply tell git to revert a commit, which does not even have to be the last one.

Sometimes you may want to undo a whole commit with all changes. The bad commit remains there and accessible, but this is usually not a big deal, unless the file contains sensitive information. This is the most natural way to fix an error, always safe and totally non-destructive, and how you should do it 99% of the time. Simply remove or fix the bad file in a new commit and push it to the remote repository. But you should do it rather fast before anyone fetches the bad commits, or you won't be very popular with them for a while )įirst two alternatives that will keep the history intact: Alternative: Correct the mistake in a new commit So you've just pushed your local branch to a remote branch, but then realized that one of the commits should not be there, or that there was some unacceptable typo in it. About Git HowTo: revert a commit already pushed to a remote repository May 2010

Git push branch to remote