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