What are the practical consequences of rewriting GIT history?

Our project has been using git for a week or so now, and we’re all enjoying it a lot (usíng it in a tight collaborative group turns out to be quite a different git experience). To keep things as simple as possible, we do not do any rebasing or history modifications. But we did make a few mistakes in the first week. A few commits were made that shouldn’t have been done, and we managed to merge a feature branch into the wrong integration branch (1.1 instead of 1.0). And we didn’t find out about these things until they were long into our history.

Now I see a lot of warnings about rewriting history, but I’m not really sure I understand the dangers involved. We use a shared bare repository, and all branches are pushed there for backup.

  • SSH - Permission denied (cannot authenticate git@github.com) via CMD
  • Change the binary that Git uses to invoke GnuPG for signing commits?
  • git push heroku - stop heroku pushing/uploading massive file
  • Differences between git fetch and git fetch origin master
  • How can I easily fixup a past commit?
  • undoing a pull from the wrong github repository
  • I would expect that if you rewrite history (say remove a commit), the full list of subsequent commits will “lose” that commit (and maybe not compile/work). I would also expect that if this happens I could actually choose to fix this at the top of history (and just leave that part of history as non-compiling).

    • If I rewrite history (and everything compiles/works in all affected branches), will my co-workers need to do any special commands)? (In other words, will they “know that I have done it” if I did it well?)
    • Will any users with local changes that I do not know about be eligible for merge failures on git pull?
    • Am I missing anything essential here?

    Any references to articles/tutorials on this subject would also be really nice.

  • Setting remote to use specified port for ssh
  • why my file permission being changed after pull from git repository
  • Why is Commit Greyed-out in Eclipse's Egit
  • Git fails to push to ftp-server
  • How can DVCS help scientific programming?
  • Git stash fails 'error: unable to resolve reference refs/stash: No such file or directory'
  • 2 Solutions collect form web for “What are the practical consequences of rewriting GIT history?”

    Required reading is Problems with rewriting history in the Git User’s Manual.

    If I rewrite history (and everything compiles/works in all affected branches), will my co-workers need to do any special commands (i.e. will they “know that I have done it” if I did it well?)?

    They will know, and Git will tell them in no uncertain terms that something is wrong. They will get unexpected error messages, and may in the process of trying to resolve the resulting merge conflicts, inadvertently revert previous commits. This problem creates a real message, and if you’re curious to see what happens you can always try it on a temporary copy of your repositories.

    Will any users with local changes that I do not know about be eligible for merge failures on git pull ?

    Absolutely, see above.

    Am I missing anything essential here ?

    Avoid rewriting history at (almost) all costs!

    As mentioned in the other answer comments, in practice each commit is unique and rewriting history will make new commits. You can think of it as cutting off the branches of a tree and then instantly growing new ones, that may even look the same, but aren’t. Yes, voodoo magic. In this analogy, reverting would be almost like supporting a falling branch with a log, so it will grow its way without falling down.

    Well, here are few good reasons to rewrite history:

    • Slim down a private repository before going public.
    • Remove sensitive data from a private repo before going public.
    • Create a new local private branch, test, test, rewrite, push. Quite valid.

    Those already reveal what Greg already said: rewriting history will screw up everyone if the repository is public (pushed commits). I also advocate on avoid doing it at all costs even in private repos, just to keep the good habit. Indeed rewriting history should be avoided at all costs*

    But there is at least another good philosophical and highly overlooked reason: rewritten history is data lost. True, a git history with revert looks messier at first than a reseted one. But if properly written, all that “mess” can be hidden away in separated branches and still we can see precisely at what point a revert was done. And even write reasons to why it was done. I think for most of the time this is more important that an apparently cleaner wiped history.

    Back to the tree analogy, even if you do remove the supporting log, the reverted branch will show the sinuous growing curves, and it is beautiful!

    * This means to just give proper consideration before doing it. Weight up the pros and cons.

    Git Baby is a git and github fan, let's start git clone.