on Wed Mar 21 2012, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
Of course, once you changed history, you weren't able to push your changes back to your fork, since history was not the same between the two. A forced push would have fixed it, but that isn't really accepted practice for anything that has been published.
The important lesson here is to never rebase across boundaries of published repositories. Only rebase if only local repositories will be affected by it.
It's a little more complicated than that. IIUC you can rewrite published history, but it's got to be marked as volatile so people don't expect it to remain static. I usually do this by naming the branch volatile/<something>, but I think it might be reasonable to consider all feature or topic branches to be volatile. In git-flow, those are named feature/<something>. In topgit, they're named t/<something>. Seems everyone uses that kind of naming convention. You might do this, for example, when you submit a pull request and the upstream maintainer tells you to change something about the way you wrote your code (e.g. naming convention). In order to keep a clean and understandable revision history in the main repository, you might go back and rewrite your commits, the force-push the new branch head and resubmit the pull request.
Or if you want to treat forks as just a snapshot of your local repo, just force push, but people won't be able to maintain a clone of your fork.
They can, if they know how to deal with it. They have to rebase any work on the upstream master. The easy way is to "git pull --rebase" when incorporating upstream history. You can set this up to happen automatically with autosetuprebase (http://www.espians.com/getting-started-with-git.html#rebase) -- Dave Abrahams BoostPro Computing http://www.boostpro.com