From a93ea3ef2756a08be7327badb3f04500a9971a68 Mon Sep 17 00:00:00 2001 From: Oleg Broytman Date: Tue, 28 Jun 2016 19:10:18 +0300 Subject: [PATCH] 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. --- pep-103.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/pep-103.txt b/pep-103.txt index ab2c351..bbcb3d4 100644 --- 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 =========== -- 2.39.2