Fix a minor misspelling

[git-wiki.git] / pep-103.txt

diff --git a/pep-103.txt b/pep-103.txt
index e953e0707bb644f809ca7b1c70baeb9363171ec3..d11403345a0d6bd24fc863992becc4ac7b907f23 100644 (file)
--- a/pep-103.txt
+++ b/pep-103.txt
@@ -592,10 +592,10 @@ that it is very much recommended not to rebase published commits the
 question's diminished even further: "whether to use rebase on
 non-pushed commits?"
 
-That small question is for the team to decide. The author of the PEP
-recommends to use rebase when pulling, i.e. always do ``git pull
---rebase`` or even configure automatic setup of rebase for every new
-branch::
+That small question is for the team to decide. To preserve the beauty
+of linear history it's recommended to use rebase when pulling, i.e. do
+``git pull --rebase`` or even configure automatic setup of rebase for
+every new branch::
 
     $ git config branch.autosetuprebase always
 
@@ -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
 ===========
@@ -763,7 +775,7 @@ working tree::
     $ git config rerere.autoupdate true
 
 You don't need to turn rerere on globally - you don't want rerere in
-bare repositories or single-branche repositories; you only need rerere
+bare repositories or single-branch repositories; you only need rerere
 in repos where you often perform merges and resolve merge conflicts.
 
 See `Rerere <https://git-scm.com/book/en/Git-Tools-Rerere>`_ in The