`Git Magic
<http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html>`_,
-also with a number of translations.
+with a number of translations.
`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
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: one can review collected patches before
+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.
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) use ``git diff HEAD``.
+(i.e., both collected and uncollected patches) run ``git diff HEAD``.
See `WhatIsTheIndex
<https://git.wiki.kernel.org/index.php/WhatIsTheIndex>`_ and
ReReRe
======
-https://git-scm.com/book/en/Git-Tools-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 repositories without branches; 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
+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`` can be used for maintenance. Git 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
-frequent (biweekly or monthly) for lesser active projects.
+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).
-Another way to do it is to run ``git repack``.
+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
for explanation on the effects of these parameters.
From time to time run ``git fsck [--strict]`` to verify integrity of
-the database.
+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
===============
-TODO: sticky options; example: git grep -O.
+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 it
+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 found files to a program; default
+program for ``-O`` is pager (usually ``less``), but you can use your
+editor::
+
+ $ git grep -Ovim # but not -O vim
+
+BTW, there is a difference between running ``git grep -O`` and ``git
+grep -Oless`` - in the latter case ``git grep`` passes ``+/pattern``
+option to less.
+
+bash/zsh completion
+-------------------
-TODO: tricky options; example: git log -p3.
+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 preinstalled 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.
-TODO: bash/zsh completion, bash/zsh prompt.
-https://git.kernel.org/cgit/git/git.git/tree/contrib/completion
+If you don't have necessary bits preinstalled, 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
=============
-TODO: anonymous access (``git daemon``); git over ssh; gitolite;
-gitweb; cgit; gitlab.
+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 has a
+lot of documentation.
-http://gitolite.com/gitolite/index.html
+TODO: gitweb; cgit; Kallithea; pagure; gogs and gitea; gitlab.
https://git.kernel.org/cgit/git/git.git/tree/gitweb
http://git.zx2c4.com/cgit/
+https://kallithea-scm.org/
+
+https://pagure.io/
+
+http://gogs.io/ and http://gitea.io/
+
+https://about.gitlab.com/
+
+
From Mercurial to git
=====================
projects / git-wiki.git / blobdiff