X-Git-Url: https://git.phdru.name/?a=blobdiff_plain;f=pep-git.txt;h=5a4ec8000d94ef03b5430ee43e47d44ad6d7597b;hb=0a82f945a179e687d2837db1cab3c18784b27e29;hp=f3b5e5551905cf3322f1dadb9aea4c1a10782fad;hpb=5200492373a6f0b13a1f7c585ceaba02d067bf78;p=git-wiki.git diff --git a/pep-git.txt b/pep-git.txt index f3b5e55..5a4ec80 100644 --- a/pep-git.txt +++ b/pep-git.txt @@ -662,7 +662,7 @@ 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) use ``git diff HEAD``. +(i.e., both collected and uncollected patches) run ``git diff HEAD``. See `WhatIsTheIndex `_ and @@ -674,25 +674,97 @@ Wiki. 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 history and finish a +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. -Database maintenance -==================== +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. -TODO: dangling objects, git gc, git repack. +See `Rerere `_ in The +Book. -https://gcc.gnu.org/ml/gcc/2007-12/msg00165.html -http://vcscompare.blogspot.ru/2008/06/git-repack-parameters.html +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 +`_ 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 +`_ +for explanation on 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 =============== -TODO: sticky options; example: git grep -O. +Command-line options and arguments +---------------------------------- + +`git help cli +`_ +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``. -TODO: tricky options; example: git log -p3. +Some options have arguments, some even have default arguments. In that +case the argument for such option must be spelled in 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 (ususally ``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. TODO: bash/zsh completion, bash/zsh prompt. https://git.kernel.org/cgit/git/git.git/tree/contrib/completion @@ -702,7 +774,7 @@ git on server ============= TODO: anonymous access (``git daemon``); git over ssh; gitolite; -gitweb; cgit; gitlab. +gitweb; cgit; Kallithea; pagure; gogs and gitea; gitlab. http://gitolite.com/gitolite/index.html @@ -710,6 +782,15 @@ 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 =====================