Rebasing published branches?

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?

Hi Josef,

On 7 November 2012 07:18, Josef Wolf <jw@raven.inka.de> wrote:

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

On 06/11/2012 8:18 pm, Josef Wolf wrote:

The major trouble with making rewritten branches public is one of merges.

Assume I have two local repos, A and B, sharing a single remote. I create a branch in A, push it to the remote, then fetch it into B. I then re-write the branch in A and force-push it, and fetch from B.

As far as B is now concerned, its local history diverges from the remote's -- a scenario which must be resolved, usually through a merge, before any work can be pushed. Unfortunately, this merge merges together the two versions of history -- the old one from B's local history, and the new one from the remote -- leading to a mess. If B then pushes, this mess is published.

So "published", in the "don't rewrite published branches" sense, means "a branch which someone else might regularly pull from, and in doing so merge together two versions of history".

In general, remembering that you've pushed rewritten history, and to makes sure that you haven't merged two versions of history after a merge/pull, is sufficient. After rewriting history on a remote, rebase / pull --rebase on a local, un-rewritten branch is sufficient to avoid the merging-two-versions-of-history nightmare.

See "RECOVERING FROM UPSTREAM REBASE" in man git-rebase for a more in-depth explanation and more discussion of solutions.

Rebasing a branch which is about to be deleted (after merging, presumably) is generally regarded as fine, provided you're not expecting people to base work on the branch before it's rewritten.

Antony