Hi Josef, On 7 November 2012 07:18, Josef Wolf <jw@xxxxxxxxxxxxx> wrote: > > Hello, > > I know, I should never rebase published branches. But... > > I frequently work on different computers and would like to share my private > branches across them. When done and the feature is in a good shape, I'd like > to rebase to clean up history before I make it available to other people. > > I guess rebasing such branches would be OK as long as I can reliably remember > to delete those branches on _all_ the clones I ever created. > > But waht if I ever make a mistake? How would one recover from such rebase > disasters? Anybody knows a good description how such a recover would be done? The only real problem you should encounter is not knowing which repository holds the 'true' feature branch, that is the one which you want to publish. The reason why rebasing public branches (where 'public' means somebody _else_ is tracking your branch) is bad is that you are rewriting somebody else's history. This can cause headache and pain for them if they have based work off what you have already published. In your situation, you are the only one working on these feature branches, and you know that you plan to rebase them. There is little risk of you rewriting someone else's history, and even if you did it is clear that these branches were always meant to be rebased so you should surprise anyone. As a practical note, you'll probably find it easier to keep track of the current state of your feature if you use one repository as your own 'blessed' repository. After working on a clone somewhere, always push to the blessed repository, and sync from it before you start work. This way you will always have the correct version of your feature branch. If worse comes to worse (somehow) remember that rebasing does not delete the old commits, just recreates them and points the branch at the recreated versions. The old versions of these commits should be available in the reflog, at least for a few weeks after the rebase. Regards, Andrew Ardill -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html