Re: Rebasing published branches?

From: Antony Male <antony.male@gmail.com>
Date: Nov 6, 2012, 23:14 UTC
Message-ID: <509999EB.5050407@gmail.com>
In-Reply-To: <20121106201822.GE28437@raven.wolf.lan>

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

> Hello,
>
> I know, I should never rebase published branches. But...

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.

> 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.

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