Redraw the diagram

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

diff --git a/pep-git.txt b/pep-git.txt
index 2b55d6341cc55f7a9ceb87e9010ef0d680d97c18..d45ef5d9379d48d4510fa168d9a3514085917a43 100644 (file)
--- a/pep-git.txt
+++ b/pep-git.txt
@@ -3,7 +3,7 @@ Title: Collecting information about git
 Version: $Revision$
 Last-Modified: $Date$
 Author: Oleg Broytman <phd@phdru.name>
 Version: $Revision$
 Last-Modified: $Date$
 Author: Oleg Broytman <phd@phdru.name>

-Status: Active
+Status: Draft

 Type: Informational
 Content-Type: text/x-rst
 Created: 01-Jun-2015
 Type: Informational
 Content-Type: text/x-rst
 Created: 01-Jun-2015


@@ -389,11 +389,11 @@ Merge or rebase?
 Internet is full of heated discussions on the topic: "merge or
 rebase?" Most of them are meaningless. When a DVCS is being used in a
 big team with a big and complex project with many branches there is
 Internet is full of heated discussions on the topic: "merge or
 rebase?" Most of them are meaningless. When a DVCS is being used in a
 big team with a big and complex project with many branches there is

-simply no way to avoid merges. So the question diminished to "whether
-to use rebase, and if yes - when to use rebase?" Considering that it
-is very much recommended not to rebase published commits the question
-diminished even further: "whether to use rebase on non-pushed
-commits?"
+simply no way to avoid merges. So the question's diminished to
+"whether to use rebase, and if yes - when to use rebase?" Considering
+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
 
 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


@@ -406,7 +406,11 @@ and configure rebase for existing branches::
 
     $ git config branch.NAME.rebase true
 
 
     $ git config branch.NAME.rebase true
 

-After that ``git pull origin v2`` will be equivalent to ``git pull
+For example::
+
+    $ git config branch.v2.rebase true
+
+After that ``git pull origin v2`` becomes equivalent to ``git pull

 --rebase origin v2``.
 
 In case when merge is preferred it is recommended to create new
 --rebase origin v2``.
 
 In case when merge is preferred it is recommended to create new


@@ -428,9 +432,9 @@ workflow would be something like::
 When the topic branch is deleted only the label is removed, commits
 are stayed in the database, they are now merged into v2::
 
 When the topic branch is deleted only the label is removed, commits
 are stayed in the database, they are now merged into v2::
 

-    --o--o--o--o--o--o-M-<v2 - it is the mainline branch
-            \         /
-             --*--*--*       - it is the topic branch, now unnamed
+    o--o--o--o--o--M--< v2 - it is the mainline branch
+        \         /
+         --*--*--*         - it is the topic branch, now unnamed

 
 The topic branch is deleted to avoid cluttering branch namespace with
 small topic branches. Information on what issue was fixed or what
 
 The topic branch is deleted to avoid cluttering branch namespace with
 small topic branches. Information on what issue was fixed or what