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
::
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
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
===========
$ 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
<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,