Don't mention the author of the PEP

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

diff --git a/pep-103.txt b/pep-103.txt
index d85e06027fdb9a19196177f3f1e08c156f013617..ab2c351ec6f580145276637032aa0562bfccc079 100644 (file)
--- a/pep-103.txt
+++ b/pep-103.txt
@@ -62,6 +62,8 @@ many different languages. Download Russian translation from `GArik
 
 `Git Wiki <https://git.wiki.kernel.org/index.php/Main_Page>`_.
 
+`Git Buch <http://gitbu.ch/index.html>`_ (German).
+
 
 Offline documentation
 ---------------------
@@ -191,10 +193,28 @@ remote-tracking branches, creates a local branch ``v1``, configure it
 to track upstream remotes/origin/v1 branch and checks out ``v1`` into
 the working directory.
 
+Some commands, like ``git status --branch`` and ``git branch --verbose``,
+report the difference between local and remote branches.
+Please remember they only do comparison with remote-tracking branches
+in your local repository, and the state of those remote-tracking
+branches can be outdated. To update remote-tracking branches you
+either fetch and merge (or rebase) commits from the remote repository
+or update remote-tracking branches without updating local branches.
+
 
 Updating local and remote-tracking branches
 -------------------------------------------
 
+To update remote-tracking branches without updating local branches run
+``git remote update [$REMOTE...]``. For example::
+
+    $ git remote update
+    $ git remote update origin
+
+
+Fetch and pull
+''''''''''''''
+
 There is a major difference between
 
 ::
@@ -572,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
 
@@ -876,7 +896,11 @@ Web interface to browse repositories can be created using `gitweb
 <https://git.kernel.org/cgit/git/git.git/tree/gitweb>`_ or `cgit
 <http://git.zx2c4.com/cgit/about/>`_. Both are CGI scripts (written in
 Perl and C). In addition to web interface both provide read-only dumb
-http access for git (http(s):// URLs).
+http access for git (http(s):// URLs). `Klaus
+<https://pypi.python.org/pypi/klaus>`_ is a small and simple WSGI web
+server that implements both web interface and git smart HTTP
+transport; supports Python 2 and Python 3, performs syntax
+highlighting.
 
 There are also more advanced web-based development environments that
 include ability to manage users, groups and projects; private,
@@ -885,10 +909,11 @@ trackers, wiki pages, pull requests and other tools for development
 and communication. Among these environments are `Kallithea
 <https://kallithea-scm.org/>`_ and `pagure <https://pagure.io/>`_,
 both are written in Python; pagure was written by Fedora developers
-and is being used to develop some Fedora projects. `Gogs
-<https://gogs.io/>`_ is written in Go; there is a fork `Gitea
-<http://gitea.io/>`_. `GitBucket
-<https://takezoe.github.io/gitbucket/about/>`_ is written in Scala.
+and is being used to develop some Fedora projects. `GitPrep
+<http://gitprep.yukikimoto.com/>`_ is yet another Github clone,
+written in Perl. `Gogs <https://gogs.io/>`_ is written in Go.
+`GitBucket <https://takezoe.github.io/gitbucket/about/>`_ is written
+in Scala.
 
 And last but not least, `Gitlab <https://about.gitlab.com/>`_. It's
 perhaps the most advanced web-based development environment for git.