Explain the problem with long-lived merged branches

It's hard to rebase a branch that was merged even if you haven't pushed
them yet.

diff --git a/pep-103.txt b/pep-103.txt
index ab2c351ec6f580145276637032aa0562bfccc079..bbcb3d46408a8d9f6054cff8e42f9ed52d8616b1 100644 (file)
--- a/pep-103.txt
+++ b/pep-103.txt
@@ -638,6 +638,18 @@ The topic branch is deleted to avoid cluttering branch namespace with
 small topic branches. Information on what issue was fixed or what
 feature was implemented should be in the commit messages.
 
+But even that small amount of rebasing could be too big in case of
+long-lived merged branches. Imagine you're doing work in both ``v1``
+and ``master`` branches, regularly merging ``v1`` into ``master``.
+After some time you will have a lot of merge and non-merge commits in
+``master``. Then you want to push your finished work to a shared
+repository and find someone has pushed a few commits to ``v1``. Now
+you have a choice of two equally bad alternatives: either you fetch
+and rebase ``v1`` and then have to recreate all you work in ``master``
+(reset ``master`` to the origin, merge ``v1`` and cherry-pick all
+non-merge commits from the old master); or merge the new ``v1`` and
+loose the beauty of linear history.
+
 
 Null-merges
 ===========