+Null-merges
+===========
+
+Git has a builtin merge strategy for what Python core developers call
+"null-merge"::
+
+ $ git merge -s ours v1 # null-merge v1 into master
+
+
+Advanced configuration
+======================
+
+Line endings
+------------
+
+Git has builtin mechanisms to handle line endings between platforms
+with different end-of-line styles. To allow git to do CRLF conversion
+assign ``text`` attribute to files using `.gitattributes
+<https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html>`_.
+For files that have to have specific line endings assign ``eol``
+attribute. For binary files the attribute is, naturally, ``binary``.
+
+For example::
+
+ $ cat .gitattributes
+ *.py text
+ *.txt text
+ *.png binary
+ /readme.txt eol=CRLF
+
+To check what attributes git uses for files use ``git check-attr``
+command. For example::
+
+$ git check-attr -a -- \*.py
+
+
+Advanced topics
+===============
+
+Staging area
+------------
+
+Staging area aka index aka cache is a distinguishing feature of git.
+Staging area is where git collects patches before committing them.
+Separation between collecting patches and commit phases provides a
+very useful feature of git: you can review collected patches before
+commit and even edit them - remove some hunks, add new hunks and
+review again.
+
+To add files to the index use ``git add``. Collecting patches before
+committing means you need to do that for every change, not only to add
+new (untracked) files. To simplify committing in case you just want to
+commit everything without reviewing run ``git commit --all`` (or just
+``-a``) - the command adds every changed tracked file to the index and
+then commit. To commit a file or files regardless of patches collected
+in the index run ``git commit [--only|-o] -- $FILE...``.
+
+To add hunks of patches to the index use ``git add --patch`` (or just
+``-p``). To remove collected files from the index use ``git reset HEAD
+-- $FILE...`` To add/inspect/remove collected hunks use ``git add
+--interactive`` (``-i``).
+
+To see the diff between the index and the last commit (i.e., collected
+patches) use ``git diff --cached``. To see the diff between the
+working tree and the index (i.e., uncollected patches) use just ``git
+diff``. To see the diff between the working tree and the last commit
+(i.e., both collected and uncollected patches) run ``git diff HEAD``.
+
+See `WhatIsTheIndex
+<https://git.wiki.kernel.org/index.php/WhatIsTheIndex>`_ and
+`IndexCommandQuickref
+<https://git.wiki.kernel.org/index.php/IndexCommandQuickref>`_ in Git
+Wiki.
+
+
+ReReRe
+======
+
+Rerere is a mechanism that helps to resolve repeated merge conflicts.
+The most frequent source of recurring merge conflicts are topic
+branches that are merged into mainline and then the merge commits are
+removed; that's often performed to test the topic branches and train
+rerere; merge commits are removed to have clean linear history and
+finish the topic branch with only one last merge commit.
+
+Rerere works by remembering the states of tree before and after a
+successful commit. That way rerere can automatically resolve conflicts
+if they appear in the same files.
+
+Rerere can be used manually with ``git rerere`` command but most often
+it's used automatically. Enable rerere with these commands in a
+working tree::
+
+ $ git config rerere.enabled true
+ $ 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
+in repos where you often perform merges and resolve merge conflicts.
+
+See `Rerere <https://git-scm.com/book/en/Git-Tools-Rerere>`_ in The
+Book.
+
+
+Database maintenance
+====================
+
+Git object database and other files/directories under ``.git`` require
+periodic maintenance and cleanup. For example, commit editing left
+unreferenced objects (dangling objects, in git terminology) and these
+objects should be pruned to avoid collecting cruft in the DB. The
+command ``git gc`` is used for maintenance. Git automatically runs
+``git gc --auto`` as a part of some commands to do quick maintenance.
+Users are recommended to run ``git gc --aggressive`` from time to
+time; ``git help gc`` recommends to run it every few hundred
+changesets; for more intensive projects it should be something like
+once a week and less frequently (biweekly or monthly) for lesser
+active projects.
+
+``git gc --aggressive`` not only removes dangling objects, it also
+repacks object database into indexed and better optimized pack(s); it
+also packs symbolic references (branches and tags). Another way to do
+it is to run ``git repack``.
+
+There is a well-known `message
+<https://gcc.gnu.org/ml/gcc/2007-12/msg00165.html>`_ from Linus
+Torvalds regarding "stupidity" of ``git gc --aggressive``. The message
+can safely be ignored now. It is old and outdated, ``git gc
+--aggressive`` became much better since that time.
+
+For those who still prefer ``git repack`` over ``git gc --aggressive``
+the recommended parameters are ``git repack -a -d -f --depth=20
+--window=250``. See `this detailed experiment
+<http://vcscompare.blogspot.ru/2008/06/git-repack-parameters.html>`_
+for explanation of the effects of these parameters.
+
+From time to time run ``git fsck [--strict]`` to verify integrity of
+the database. ``git fsck`` may produce a list of dangling objects;
+that's not an error, just a reminder to perform regular maintenance.
+
+
+Tips and tricks
+===============
+
+Command-line options and arguments
+----------------------------------
+
+`git help cli
+<https://www.kernel.org/pub/software/scm/git/docs/gitcli.html>`_
+recommends not to combine short options/flags. Most of the times
+combining works: ``git commit -av`` works perfectly, but there are
+situations when it doesn't. E.g., ``git log -p -5`` cannot be combined
+as ``git log -p5``.
+
+Some options have arguments, some even have default arguments. In that
+case the argument for such option must be spelled in a sticky way:
+``-Oarg``, never ``-O arg`` because for an option that has a default
+argument the latter means "use default value for option ``-O`` and
+pass ``arg`` further to the option parser". For example, ``git grep``
+has an option ``-O`` that passes a list of names of the found files to
+a program; default program for ``-O`` is a pager (usually ``less``),
+but you can use your editor::
+
+ $ git grep -Ovim # but not -O vim
+
+BTW, if git is instructed to use ``less`` as the pager (i.e., if pager
+is not configured in git at all it uses ``less`` by default, or if it
+gets ``less`` from GIT_PAGER or PAGER environment variables, or if it
+was configured with ``git config --global core.pager less``, or
+``less`` is used in the command ``git grep -Oless``) ``git grep``
+passes ``+/$pattern`` option to ``less`` which is quite convenient.
+Unfortunately, ``git grep`` doesn't pass the pattern if the pager is
+not exactly ``less``, even if it's ``less`` with parameters (something
+like ``git config --global core.pager less -FRSXgimq``); fortunately,
+``git grep -Oless`` always passes the pattern.
+
+
+bash/zsh completion
+-------------------
+
+It's a bit hard to type ``git rebase --interactive --preserve-merges
+HEAD~5`` manually even for those who are happy to use command-line,
+and this is where shell completion is of great help. Bash/zsh come
+with programmable completion, often automatically installed and
+enabled, so if you have bash/zsh and git installed, chances are you
+are already done - just go and use it at the command-line.
+
+If you don't have necessary bits installed, install and enable
+bash_completion package. If you want to upgrade your git completion to
+the latest and greatest download necessary file from `git contrib
+<https://git.kernel.org/cgit/git/git.git/tree/contrib/completion>`_.
+
+Git-for-windows comes with git-bash for which bash completion is
+installed and enabled.
+
+
+bash/zsh prompt
+---------------
+
+For command-line lovers shell prompt can carry a lot of useful
+information. To include git information in the prompt use
+`git-prompt.sh
+<https://git.kernel.org/cgit/git/git.git/tree/contrib/completion/git-prompt.sh>`_.
+Read the detailed instructions in the file.
+
+Search the Net for "git prompt" to find other prompt variants.
+
+
+git on server
+=============
+
+The simplest way to publish a repository or a group of repositories is
+``git daemon``. The daemon provides anonymous access, by default it is
+read-only. The repositories are accessible by git protocol (git://
+URLs). Write access can be enabled but the protocol lacks any
+authentication means, so it should be enabled only within a trusted
+LAN. See ``git help daemon`` for details.
+
+Git over ssh provides authentication and repo-level authorisation as
+repositories can be made user- or group-writeable (see parameter
+``core.sharedRepository`` in ``git help config``). If that's too
+permissive or too restrictive for some project's needs there is a
+wrapper `gitolite <http://gitolite.com/gitolite/index.html>`_ that can
+be configured to allow access with great granularity; gitolite is
+written in Perl and has a lot of documentation.
+
+Web interface to browse repositories can be created using `gitweb
+<https://git.kernel.org/cgit/git/git.git/tree/gitweb>`_ and `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).
+
+There are also more advanced web-based development environments that
+include ability to manage users, groups and projects; private, group
+and public repositories; they often include issue 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
+<http://gogs.io/>`_ is written in Go; there is a fork `Gitea
+<http://gitea.io/>`_.
+
+And last but not least `Gitlab <https://about.gitlab.com/>`_. It's
+perhaps the most advanced web-based development environment for git.
+Written in Ruby, community edition is free and open source (MIT
+license).
+
+
+From Mercurial to git
+=====================
+
+There are many tools to convert Mercurial repositories to git. The
+most famous are, perhaps, `hg-git <https://hg-git.github.io/>`_ and
+`fast-export <http://repo.or.cz/w/fast-export.git>`_ (many years ago
+it was known under the name ``hg2git``).
+
+But a better tool, perhaps the best, is `git-remote-hg
+<https://github.com/felipec/git-remote-hg>`_. It provides transparent
+bidirectional access (pull and push) to Mercurial repositories from
+git. The author wrote a `comparison of alternatives
+<https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives>`_
+that seems to be mostly unbiased.
+
+To use git-remote-hg, install or clone it, add to your PATH (or copy
+script ``git-remote-hg`` to a directory that's already in PATH) and
+prepend ``hg::`` to Mercurial URLs. For example::
+
+ $ git clone https://github.com/felipec/git-remote-hg.git
+ $ PATH=$PATH:"`pwd`"/git-remote-hg
+ $ git clone hg::https://hg.python.org/peps/ PEPs
+
+To work with the repository just use regular git commands including
+``git fetch/pull/push``.
+
+To start converting your Mercurial habits to git see the page
+`Mercurial for Git users
+<https://mercurial.selenic.com/wiki/GitConcepts>`_ at Mercurial wiki.
+At the second half of the page there is a table that lists
+corresponding Mercurial and git commands. Should work perfectly in
+both directions.