Canonical address for kernel.org is www.kernel.org

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

diff --git a/pep-git.txt b/pep-git.txt
index a9b4d9ea3b37911fbdc6431541bc7a419946637c..6365fb8c0825bedc7ebe0c2f2b48666f73d8ed91 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


@@ -45,13 +45,13 @@ Git Tutorial: `part 1
 `Git workflows
 <https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>`_.
 
 `Git workflows
 <https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>`_.
 

+Advanced documentation
+----------------------
+

 `Git Magic
 <http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html>`_,
 also with a number of translations.
 
 `Git Magic
 <http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html>`_,
 also with a number of translations.
 

-Advanced documentation
-----------------------
-

 `Pro Git <https://git-scm.com/book>`_. The Book about git. Buy it at
 Amazon or download in PDF, mobi, or ePub form. Has translations to
 many different languages. Download Russian translation from `GArik
 `Pro Git <https://git-scm.com/book>`_. The Book about git. Buy it at
 Amazon or download in PDF, mobi, or ePub form. Has translations to
 many different languages. Download Russian translation from `GArik


@@ -89,6 +89,9 @@ install git with `Homebrew <http://brew.sh/>`_: ``brew install git``.
 powerful Git GUI written in Python and GPL licensed. Linux, Windows,
 MacOS X.
 
 powerful Git GUI written in Python and GPL licensed. Linux, Windows,
 MacOS X.
 

+`TortoiseGit <https://tortoisegit.org/>`_ is a Windows Shell Interface
+to Git based on TortoiseSVN; open source.
+

 Initial configuration
 ---------------------
 
 Initial configuration
 ---------------------
 


@@ -216,15 +219,15 @@ is equivalent to
 ::
 
     $ git fetch REMOTE BRANCH
 ::
 
     $ git fetch REMOTE BRANCH

-    $ git merge FETCH_HEAD # FETCH_HEAD is a literal here
+    $ git merge FETCH_HEAD  # FETCH_HEAD is a literal here

 
 Certainly, BRANCH in that case should be your current branch. If you
 want to merge a different branch into your current branch first update
 that non-current branch and then merge::
 
 
 Certainly, BRANCH in that case should be your current branch. If you
 want to merge a different branch into your current branch first update
 that non-current branch and then merge::
 

-    $ git fetch origin v1:v1 # Update v1
-    $ git pull --rebase origin v2 # Update the current branch v2 using
-                                  # rebase instead of merge
+    $ git fetch origin v1:v1  # Update v1
+    $ git pull --rebase origin v2  # Update the current branch v2 using
+                                   # rebase instead of merge

     $ git merge v1
 
 If you have not yet pushed commits on ``v1``, though, the scenario has
     $ git merge v1
 
 If you have not yet pushed commits on ``v1``, though, the scenario has


@@ -377,7 +380,7 @@ TODO: describe undo strategies: git reset, git revert, git checkout,
 git reflog. "Commit early, commit often".
 
 How to undo a merge
 git reflog. "Commit early, commit often".
 
 How to undo a merge

-https://kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html
+https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html

 
 
 Merge or rebase?
 
 
 Merge or rebase?


@@ -386,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


@@ -403,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


@@ -414,20 +421,20 @@ merge the topic branch to the mainline from time to time and switch
 back to the topic branch to continue working on it. The entire
 workflow would be something like::
 
 back to the topic branch to continue working on it. The entire
 workflow would be something like::
 

-    $ git checkout -b issue-42 # create and switch to a new branch
+    $ git checkout -b issue-42  # create and switch to a new branch

         ...edit/test/commit...
     $ git checkout v2
         ...edit/test/commit...
     $ git checkout v2

-    $ git pull --rebase origin v2 # update v2 from the upstream
+    $ git pull --rebase origin v2  # update v2 from the upstream

     $ git merge issue-42
     $ git merge issue-42

-    $ git branch -d issue-42 # delete the topic branch
+    $ git branch -d issue-42  # delete the topic branch

     $ git push origin v2
 
 When the topic branch is deleted only the label is removed, commits
 are stayed in the database, they are now merged into v2::
 
     $ git push origin 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


@@ -440,7 +447,7 @@ Null-merges
 Git has a builtin strategy for what Python core developers call
 "null-merge"::
 
 Git has a builtin strategy for what Python core developers call
 "null-merge"::
 

-    $ git merge -s ours v1 # null-merge v1 into v2
+    $ git merge -s ours v1  # null-merge v1 into v2

 
 
 ReReRe
 
 
 ReReRe