Merge branch 'ss/git-gui-mergetool'

The Tcl msgcat package doesn't detect the use of a multi-lingual language
pack on Windows 7. This means that a user may have their display language
set to Japanese but the system installed langauge was English.
This patch reads the relevent registry key to fix this before loading in
the locale specific parts of git-gui.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

.gitattributes

@@ -0,0 +1,3 @@
+*           encoding=US-ASCII
+git-gui.sh  encoding=UTF-8
+/po/*.po    encoding=UTF-8

.gitignore

@@ -1,171 +1,8 @@
-GIT-CFLAGS
-GIT-GUI-VARS
-GIT-VERSION-FILE
-git
-git-add
-git-add--interactive
-git-am
-git-annotate
-git-apply
-git-archimport
-git-archive
-git-bisect
-git-blame
-git-branch
-git-bundle
-git-cat-file
-git-check-attr
-git-check-ref-format
-git-checkout
-git-checkout-index
-git-cherry
-git-cherry-pick
-git-clean
-git-clone
-git-commit
-git-commit-tree
-git-config
-git-count-objects
-git-cvsexportcommit
-git-cvsimport
-git-cvsserver
-git-daemon
-git-diff
-git-diff-files
-git-diff-index
-git-diff-tree
-git-describe
-git-fast-export
-git-fast-import
-git-fetch
-git-fetch--tool
-git-fetch-pack
-git-filter-branch
-git-fmt-merge-msg
-git-for-each-ref
-git-format-patch
-git-fsck
-git-fsck-objects
-git-gc
-git-get-tar-commit-id
-git-grep
-git-hash-object
-git-help--browse
-git-http-fetch
-git-http-push
-git-imap-send
-git-index-pack
-git-init
-git-init-db
-git-instaweb
-git-log
-git-lost-found
-git-ls-files
-git-ls-remote
-git-ls-tree
-git-mailinfo
-git-mailsplit
-git-merge
-git-merge-base
-git-merge-index
-git-merge-file
-git-merge-tree
-git-merge-octopus
-git-merge-one-file
-git-merge-ours
-git-merge-recursive
-git-merge-resolve
-git-merge-stupid
-git-merge-subtree
-git-mergetool
-git-mktag
-git-mktree
-git-name-rev
-git-mv
-git-pack-redundant
-git-pack-objects
-git-pack-refs
-git-parse-remote
-git-patch-id
-git-peek-remote
-git-prune
-git-prune-packed
-git-pull
-git-push
-git-quiltimport
-git-read-tree
-git-rebase
-git-rebase--interactive
-git-receive-pack
-git-reflog
-git-relink
-git-remote
-git-repack
-git-repo-config
-git-request-pull
-git-rerere
-git-reset
-git-rev-list
-git-rev-parse
-git-revert
-git-rm
-git-send-email
-git-send-pack
-git-sh-setup
-git-shell
-git-shortlog
-git-show
-git-show-branch
-git-show-index
-git-show-ref
-git-stash
-git-status
-git-stripspace
-git-submodule
-git-svn
-git-symbolic-ref
-git-tag
-git-tar-tree
-git-unpack-file
-git-unpack-objects
-git-update-index
-git-update-ref
-git-update-server-info
-git-upload-archive
-git-upload-pack
-git-var
-git-verify-pack
-git-verify-tag
-git-whatchanged
-git-write-tree
-git-core-*/?*
-gitk-wish
-gitweb/gitweb.cgi
-test-absolute-path
-test-chmtime
-test-date
-test-delta
-test-dump-cache-tree
-test-genrandom
-test-match-trees
-test-parse-options
-test-sha1
-common-cmds.h
-*.tar.gz
-*.dsc
-*.deb
-git.spec
-*.exe
-*.[aos]
-*.py[co]
+.DS_Store
 config.mak
-autom4te.cache
-config.cache
-config.log
-config.status
-config.mak.autogen
-config.mak.append
-configure
-tags
-TAGS
-cscope*
+Git Gui.app*
+git-gui.tcl
+GIT-VERSION-FILE
+GIT-GUI-VARS
+git-gui
+lib/tclIndex

.mailmap

@@ -1,54 +0,0 @@
-#
-# This list is used by git-shortlog to fix a few botched name translations
-# in the git archive, either because the author's full name was messed up
-# and/or not always written the same way, making contributions from the
-# same person appearing not to be so.
-#
-
-Aneesh Kumar K.V <aneesh.kumar@gmail.com>
-Brian M. Carlson <sandals@crustytoothpaste.ath.cx>
-Chris Shoemaker <c.shoemaker@cox.net>
-Dana L. How <danahow@gmail.com>
-Dana L. How <how@deathvalley.cswitch.com>
-Daniel Barkalow <barkalow@iabervon.org>
-David Kågedal <davidk@lysator.liu.se>
-Fredrik Kuivinen <freku045@student.liu.se>
-H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
-H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
-H. Peter Anvin <hpa@trantor.hos.anvin.org>
-Horst H. von Brand <vonbrand@inf.utfsm.cl>
-Joachim Berdal Haga <cjhaga@fys.uio.no>
-Jon Loeliger <jdl@freescale.com>
-Jon Seymour <jon@blackcubes.dyndns.org>
-Junio C Hamano <junio@twinsun.com>
-Karl Hasselström <kha@treskal.com>
-Kent Engstrom <kent@lysator.liu.se>
-Lars Doelle <lars.doelle@on-line ! de>
-Lars Doelle <lars.doelle@on-line.de>
-Li Hong <leehong@pku.edu.cn>
-Lukas Sandström <lukass@etek.chalmers.se>
-Martin Langhoff <martin@catalyst.net.nz>
-Michael Coleman <tutufan@gmail.com>
-Michele Ballabio <barra_cuda@katamail.com>
-Nanako Shiraishi <nanako3@bluebottle.com>
-Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
-Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
-René Scharfe <rene.scharfe@lsrfire.ath.cx>
-Robert Fitzsimons <robfitz@273k.net>
-Sam Vilain <sam@vilain.net>
-Santi Béjar <sbejar@gmail.com>
-Sean Estabrooks <seanlkml@sympatico.ca>
-Shawn O. Pearce <spearce@spearce.org>
-Steven Grimm <koreth@midwinter.com>
-Theodore Ts'o <tytso@mit.edu>
-Tony Luck <tony.luck@intel.com>
-Uwe Kleine-König <Uwe_Zeisberger@digi.com>
-Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
-Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
-Uwe Kleine-König <uzeisberger@io.fsforth.de>
-Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
-Ville Skyttä <scop@xemacs.org>
-William Pursell <bill.pursell@gmail.com>
-YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-anonymous <linux@horizon.com>
-anonymous <linux@horizon.net>

COPYING

@@ -1,361 +0,0 @@
-
- Note that the only valid version of the GPL as far as this project
- is concerned is _this_ particular version of the license (ie v2, not
- v2.2 or v3.x or whatever), unless explicitly otherwise stated.
-
- HOWEVER, in order to allow a migration to GPLv3 if that seems like
- a good idea, I also ask that people involved with the project make
- their preferences known. In particular, if you trust me to make that
- decision, you might note so in your copyright message, ie something
- like
-
-	This file is licensed under the GPL v2, or a later version
-	at the discretion of Linus.
-
-  might avoid issues. But we can also just decide to synchronize and
-  contact all copyright holders on record if/when the occasion arises.
-
-			Linus Torvalds
-
-----------------------------------------
-
-		    GNU GENERAL PUBLIC LICENSE
-		       Version 2, June 1991
-
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-                       59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-			    Preamble
-
-  The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users.  This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it.  (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.)  You can apply it to
-your programs, too.
-
-  When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
-  To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
-  For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have.  You must make sure that they, too, receive or can get the
-source code.  And you must show them these terms so they know their
-rights.
-
-  We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
-  Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software.  If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
-  Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary.  To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
-  The precise terms and conditions for copying, distribution and
-modification follow.
-
-		    GNU GENERAL PUBLIC LICENSE
-   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
-  0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License.  The "Program", below,
-refers to any such program or work, and a "work based on the Program"
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language.  (Hereinafter, translation is included without limitation in
-the term "modification".)  Each licensee is addressed as "you".
-
-Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope.  The act of
-running the Program is not restricted, and the output from the Program
-is covered only if its contents constitute a work based on the
-Program (independent of having been made by running the Program).
-Whether that is true depends on what the Program does.
-
-  1. You may copy and distribute verbatim copies of the Program's
-source code as you receive it, in any medium, provided that you
-conspicuously and appropriately publish on each copy an appropriate
-copyright notice and disclaimer of warranty; keep intact all the
-notices that refer to this License and to the absence of any warranty;
-and give any other recipients of the Program a copy of this License
-along with the Program.
-
-You may charge a fee for the physical act of transferring a copy, and
-you may at your option offer warranty protection in exchange for a fee.
-
-  2. You may modify your copy or copies of the Program or any portion
-of it, thus forming a work based on the Program, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-
-    a) You must cause the modified files to carry prominent notices
-    stating that you changed the files and the date of any change.
-
-    b) You must cause any work that you distribute or publish, that in
-    whole or in part contains or is derived from the Program or any
-    part thereof, to be licensed as a whole at no charge to all third
-    parties under the terms of this License.
-
-    c) If the modified program normally reads commands interactively
-    when run, you must cause it, when started running for such
-    interactive use in the most ordinary way, to print or display an
-    announcement including an appropriate copyright notice and a
-    notice that there is no warranty (or else, saying that you provide
-    a warranty) and that users may redistribute the program under
-    these conditions, and telling the user how to view a copy of this
-    License.  (Exception: if the Program itself is interactive but
-    does not normally print such an announcement, your work based on
-    the Program is not required to print an announcement.)
-
-These requirements apply to the modified work as a whole.  If
-identifiable sections of that work are not derived from the Program,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works.  But when you
-distribute the same sections as part of a whole which is a work based
-on the Program, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote it.
-
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Program.
-
-In addition, mere aggregation of another work not based on the Program
-with the Program (or with a work based on the Program) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-
-  3. You may copy and distribute the Program (or a work based on it,
-under Section 2) in object code or executable form under the terms of
-Sections 1 and 2 above provided that you also do one of the following:
-
-    a) Accompany it with the complete corresponding machine-readable
-    source code, which must be distributed under the terms of Sections
-    1 and 2 above on a medium customarily used for software interchange; or,
-
-    b) Accompany it with a written offer, valid for at least three
-    years, to give any third party, for a charge no more than your
-    cost of physically performing source distribution, a complete
-    machine-readable copy of the corresponding source code, to be
-    distributed under the terms of Sections 1 and 2 above on a medium
-    customarily used for software interchange; or,
-
-    c) Accompany it with the information you received as to the offer
-    to distribute corresponding source code.  (This alternative is
-    allowed only for noncommercial distribution and only if you
-    received the program in object code or executable form with such
-    an offer, in accord with Subsection b above.)
-
-The source code for a work means the preferred form of the work for
-making modifications to it.  For an executable work, complete source
-code means all the source code for all modules it contains, plus any
-associated interface definition files, plus the scripts used to
-control compilation and installation of the executable.  However, as a
-special exception, the source code distributed need not include
-anything that is normally distributed (in either source or binary
-form) with the major components (compiler, kernel, and so on) of the
-operating system on which the executable runs, unless that component
-itself accompanies the executable.
-
-If distribution of executable or object code is made by offering
-access to copy from a designated place, then offering equivalent
-access to copy the source code from the same place counts as
-distribution of the source code, even though third parties are not
-compelled to copy the source along with the object code.
-
-  4. You may not copy, modify, sublicense, or distribute the Program
-except as expressly provided under this License.  Any attempt
-otherwise to copy, modify, sublicense or distribute the Program is
-void, and will automatically terminate your rights under this License.
-However, parties who have received copies, or rights, from you under
-this License will not have their licenses terminated so long as such
-parties remain in full compliance.
-
-  5. You are not required to accept this License, since you have not
-signed it.  However, nothing else grants you permission to modify or
-distribute the Program or its derivative works.  These actions are
-prohibited by law if you do not accept this License.  Therefore, by
-modifying or distributing the Program (or any work based on the
-Program), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Program or works based on it.
-
-  6. Each time you redistribute the Program (or any work based on the
-Program), the recipient automatically receives a license from the
-original licensor to copy, distribute or modify the Program subject to
-these terms and conditions.  You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
-this License.
-
-  7. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License.  If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Program at all.  For example, if a patent
-license would not permit royalty-free redistribution of the Program by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Program.
-
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply and the section as a whole is intended to apply in other
-circumstances.
-
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system, which is
-implemented by public license practices.  Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-
-  8. If the distribution and/or use of the Program is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Program under this License
-may add an explicit geographical distribution limitation excluding
-those countries, so that distribution is permitted only in or among
-countries not thus excluded.  In such case, this License incorporates
-the limitation as if written in the body of this License.
-
-  9. The Free Software Foundation may publish revised and/or new versions
-of the General Public License from time to time.  Such new versions will
-be similar in spirit to the present version, but may differ in detail to
-address new problems or concerns.
-
-Each version is given a distinguishing version number.  If the Program
-specifies a version number of this License which applies to it and "any
-later version", you have the option of following the terms and conditions
-either of that version or of any later version published by the Free
-Software Foundation.  If the Program does not specify a version number of
-this License, you may choose any version ever published by the Free Software
-Foundation.
-
-  10. If you wish to incorporate parts of the Program into other free
-programs whose distribution conditions are different, write to the author
-to ask for permission.  For software which is copyrighted by the Free
-Software Foundation, write to the Free Software Foundation; we sometimes
-make exceptions for this.  Our decision will be guided by the two goals
-of preserving the free status of all derivatives of our free software and
-of promoting the sharing and reuse of software generally.
-
-			    NO WARRANTY
-
-  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
-FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
-OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
-PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
-OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
-TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
-PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-
-  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
-WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
-REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
-INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
-OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
-TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
-YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
-PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.
-
-		     END OF TERMS AND CONDITIONS
-
-	    How to Apply These Terms to Your New Programs
-
-  If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these terms.
-
-  To do so, attach the following notices to the program.  It is safest
-to attach them to the start of each source file to most effectively
-convey the exclusion of warranty; and each file should have at least
-the "copyright" line and a pointer to where the full notice is found.
-
-    <one line to give the program's name and a brief idea of what it does.>
-    Copyright (C) <year>  <name of author>
-
-    This program is free software; you can redistribute it and/or modify
-    it under the terms of the GNU General Public License as published by
-    the Free Software Foundation; either version 2 of the License, or
-    (at your option) any later version.
-
-    This program is distributed in the hope that it will be useful,
-    but WITHOUT ANY WARRANTY; without even the implied warranty of
-    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-    GNU General Public License for more details.
-
-    You should have received a copy of the GNU General Public License
-    along with this program; if not, write to the Free Software
-    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
-
-
-Also add information on how to contact you by electronic and paper mail.
-
-If the program is interactive, make it output a short notice like this
-when it starts in an interactive mode:
-
-    Gnomovision version 69, Copyright (C) year name of author
-    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
-    This is free software, and you are welcome to redistribute it
-    under certain conditions; type `show c' for details.
-
-The hypothetical commands `show w' and `show c' should show the appropriate
-parts of the General Public License.  Of course, the commands you use may
-be called something other than `show w' and `show c'; they could even be
-mouse-clicks or menu items--whatever suits your program.
-
-You should also get your employer (if you work as a programmer) or your
-school, if any, to sign a "copyright disclaimer" for the program, if
-necessary.  Here is a sample; alter the names:
-
-  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
-  `Gnomovision' (which makes passes at compilers) written by James Hacker.
-
-  <signature of Ty Coon>, 1 April 1989
-  Ty Coon, President of Vice
-
-This General Public License does not permit incorporating your program into
-proprietary programs.  If your program is a subroutine library, you may
-consider it more useful to permit linking proprietary applications with the
-library.  If this is what you want to do, use the GNU Library General
-Public License instead of this License.

Documentation/.gitignore

@@ -1,8 +0,0 @@
-*.xml
-*.html
-*.[1-8]
-*.made
-git.info
-howto-index.txt
-doc.dep
-cmds-*.txt

Documentation/CodingGuidelines

@@ -1,112 +0,0 @@
-Like other projects, we also have some guidelines to keep to the
-code.  For git in general, three rough rules are:
-
- - Most importantly, we never say "It's in POSIX; we'll happily
-   ignore your needs should your system not conform to it."
-   We live in the real world.
-
- - However, we often say "Let's stay away from that construct,
-   it's not even in POSIX".
-
- - In spite of the above two rules, we sometimes say "Although
-   this is not in POSIX, it (is so convenient | makes the code
-   much more readable | has other good characteristics) and
-   practically all the platforms we care about support it, so
-   let's use it".
-
-   Again, we live in the real world, and it is sometimes a
-   judgement call, the decision based more on real world
-   constraints people face than what the paper standard says.
-
-
-As for more concrete guidelines, just imitate the existing code
-(this is a good guideline, no matter which project you are
-contributing to).  But if you must have a list of rules,
-here they are.
-
-For shell scripts specifically (not exhaustive):
-
- - We prefer $( ... ) for command substitution; unlike ``, it
-   properly nests.  It should have been the way Bourne spelled
-   it from day one, but unfortunately isn't.
-
- - We use ${parameter-word} and its [-=?+] siblings, and their
-   colon'ed "unset or null" form.
-
- - We use ${parameter#word} and its [#%] siblings, and their
-   doubled "longest matching" form.
-
- - We use Arithmetic Expansion $(( ... )).
-
- - No "Substring Expansion" ${parameter:offset:length}.
-
- - No shell arrays.
-
- - No strlen ${#parameter}.
-
- - No regexp ${parameter/pattern/string}.
-
- - We do not use Process Substitution <(list) or >(list).
-
- - We prefer "test" over "[ ... ]".
-
- - We do not write the noiseword "function" in front of shell
-   functions.
-
-For C programs:
-
- - We use tabs to indent, and interpret tabs as taking up to
-   8 spaces.
-
- - We try to keep to at most 80 characters per line.
-
- - When declaring pointers, the star sides with the variable
-   name, i.e. "char *string", not "char* string" or
-   "char * string".  This makes it easier to understand code
-   like "char *string, c;".
-
- - We avoid using braces unnecessarily.  I.e.
-
-	if (bla) {
-		x = 1;
-	}
-
-   is frowned upon.  A gray area is when the statement extends
-   over a few lines, and/or you have a lengthy comment atop of
-   it.  Also, like in the Linux kernel, if there is a long list
-   of "else if" statements, it can make sense to add braces to
-   single line blocks.
-
- - Try to make your code understandable.  You may put comments
-   in, but comments invariably tend to stale out when the code
-   they were describing changes.  Often splitting a function
-   into two makes the intention of the code much clearer.
-
- - Double negation is often harder to understand than no negation
-   at all.
-
- - Some clever tricks, like using the !! operator with arithmetic
-   constructs, can be extremely confusing to others.  Avoid them,
-   unless there is a compelling reason to use them.
-
- - Use the API.  No, really.  We have a strbuf (variable length
-   string), several arrays with the ALLOC_GROW() macro, a
-   path_list for sorted string lists, a hash map (mapping struct
-   objects) named "struct decorate", amongst other things.
-
- - When you come up with an API, document it.
-
- - The first #include in C files, except in platform specific
-   compat/ implementations, should be git-compat-util.h or another
-   header file that includes it, such as cache.h or builtin.h.
-
- - If you are planning a new command, consider writing it in shell
-   or perl first, so that changes in semantics can be easily
-   changed and discussed.  Many git commands started out like
-   that, and a few are still scripts.
-
- - Avoid introducing a new dependency into git. This means you
-   usually should stay away from scripting languages not already
-   used in the git core command set (unless your command is clearly
-   separate from it, such as an importer to convert random-scm-X
-   repositories to git).

Documentation/Makefile

@@ -1,232 +0,0 @@
-MAN1_TXT= \
-	$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
-		$(wildcard git-*.txt)) \
-	gitk.txt
-MAN5_TXT=gitattributes.txt gitignore.txt gitcli.txt gitmodules.txt
-MAN7_TXT=git.txt
-
-MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
-MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
-MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
-
-DOC_HTML=$(MAN_HTML)
-
-ARTICLES = tutorial
-ARTICLES += tutorial-2
-ARTICLES += core-tutorial
-ARTICLES += cvs-migration
-ARTICLES += diffcore
-ARTICLES += howto-index
-ARTICLES += repository-layout
-ARTICLES += hooks
-ARTICLES += everyday
-ARTICLES += git-tools
-ARTICLES += glossary
-# with their own formatting rules.
-SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual
-API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
-SP_ARTICLES += $(API_DOCS)
-SP_ARTICLES += technical/api-index
-
-DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
-
-DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
-DOC_MAN5=$(patsubst %.txt,%.5,$(MAN5_TXT))
-DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
-
-prefix?=$(HOME)
-bindir?=$(prefix)/bin
-htmldir?=$(prefix)/share/doc/git-doc
-mandir?=$(prefix)/share/man
-man1dir=$(mandir)/man1
-man5dir=$(mandir)/man5
-man7dir=$(mandir)/man7
-# DESTDIR=
-
-ASCIIDOC=asciidoc
-ASCIIDOC_EXTRA =
-MANPAGE_XSL = callouts.xsl
-INSTALL?=install
-RM ?= rm -f
-DOC_REF = origin/man
-
-infodir?=$(prefix)/share/info
-MAKEINFO=makeinfo
-INSTALL_INFO=install-info
-DOCBOOK2X_TEXI=docbook2x-texi
-ifndef PERL_PATH
-	PERL_PATH = /usr/bin/perl
-endif
-
--include ../config.mak.autogen
--include ../config.mak
-
-ifdef ASCIIDOC8
-ASCIIDOC_EXTRA += -a asciidoc7compatible
-endif
-ifdef DOCBOOK_XSL_172
-ASCIIDOC_EXTRA += -a docbook-xsl-172
-MANPAGE_XSL = manpage-1.72.xsl
-endif
-
-#
-# Please note that there is a minor bug in asciidoc.
-# The version after 6.0.3 _will_ include the patch found here:
-#   http://marc.theaimsgroup.com/?l=git&m=111558757202243&w=2
-#
-# Until that version is released you may have to apply the patch
-# yourself - yes, all 6 characters of it!
-#
-
-all: html man
-
-html: $(DOC_HTML)
-
-$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf
-
-man: man1 man5 man7
-man1: $(DOC_MAN1)
-man5: $(DOC_MAN5)
-man7: $(DOC_MAN7)
-
-info: git.info gitman.info
-
-install: man
-	$(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
-	$(INSTALL) -d -m 755 $(DESTDIR)$(man5dir)
-	$(INSTALL) -d -m 755 $(DESTDIR)$(man7dir)
-	$(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
-	$(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
-	$(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
-
-install-info: info
-	$(INSTALL) -d -m 755 $(DESTDIR)$(infodir)
-	$(INSTALL) -m 644 git.info gitman.info $(DESTDIR)$(infodir)
-	if test -r $(DESTDIR)$(infodir)/dir; then \
-	  $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
-	  $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) gitman.info ;\
-	else \
-	  echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \
-	fi
-
-install-html: html
-	sh ./install-webdoc.sh $(DESTDIR)$(htmldir)
-
-../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
-	$(MAKE) -C ../ GIT-VERSION-FILE
-
--include ../GIT-VERSION-FILE
-
-#
-# Determine "include::" file references in asciidoc files.
-#
-doc.dep : $(wildcard *.txt) build-docdep.perl
-	$(RM) $@+ $@
-	$(PERL_PATH) ./build-docdep.perl >$@+
-	mv $@+ $@
-
--include doc.dep
-
-cmds_txt = cmds-ancillaryinterrogators.txt \
-	cmds-ancillarymanipulators.txt \
-	cmds-mainporcelain.txt \
-	cmds-plumbinginterrogators.txt \
-	cmds-plumbingmanipulators.txt \
-	cmds-synchingrepositories.txt \
-	cmds-synchelpers.txt \
-	cmds-purehelpers.txt \
-	cmds-foreignscminterface.txt
-
-$(cmds_txt): cmd-list.made
-
-cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT)
-	$(RM) $@
-	$(PERL_PATH) ./cmd-list.perl ../command-list.txt
-	date >$@
-
-git.7 git.html: git.txt
-
-clean:
-	$(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7
-	$(RM) *.texi *.texi+ git.info gitman.info
-	$(RM) howto-index.txt howto/*.html doc.dep
-	$(RM) technical/api-*.html technical/api-index.txt
-	$(RM) $(cmds_txt) *.made
-
-$(MAN_HTML): %.html : %.txt
-	$(RM) $@+ $@
-	$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
-		$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
-	mv $@+ $@
-
-%.1 %.5 %.7 : %.xml
-	$(RM) $@
-	xmlto -m $(MANPAGE_XSL) man $<
-
-%.xml : %.txt
-	$(RM) $@+ $@
-	$(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
-		$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
-	mv $@+ $@
-
-user-manual.xml: user-manual.txt user-manual.conf
-	$(ASCIIDOC) -b docbook -d book $<
-
-technical/api-index.txt: technical/api-index-skel.txt \
-	technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS))
-	cd technical && sh ./api-index.sh
-
-$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
-	$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
-		$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt
-
-XSLT = docbook.xsl
-XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
-
-user-manual.html: user-manual.xml
-	xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
-
-git.info: user-manual.texi
-	$(MAKEINFO) --no-split -o $@ user-manual.texi
-
-user-manual.texi: user-manual.xml
-	$(RM) $@+ $@
-	$(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | $(PERL_PATH) fix-texi.perl >$@+
-	mv $@+ $@
-
-gitman.texi: $(MAN_XML) cat-texi.perl
-	$(RM) $@+ $@
-	($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --to-stdout $(xml);)) | \
-	$(PERL_PATH) cat-texi.perl $@ >$@+
-	mv $@+ $@
-
-gitman.info: gitman.texi
-	$(MAKEINFO) --no-split $*.texi
-
-$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
-	$(RM) $@+ $@
-	$(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+
-	mv $@+ $@
-
-howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
-	$(RM) $@+ $@
-	sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
-	mv $@+ $@
-
-$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
-	$(ASCIIDOC) -b xhtml11 $*.txt
-
-WEBDOC_DEST = /pub/software/scm/git/docs
-
-$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
-	$(RM) $@+ $@
-	sed -e '1,/^$$/d' $< | $(ASCIIDOC) -b xhtml11 - >$@+
-	mv $@+ $@
-
-install-webdoc : html
-	sh ./install-webdoc.sh $(WEBDOC_DEST)
-
-quick-install:
-	sh ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
-
-.PHONY: .FORCE-GIT-VERSION-FILE

Documentation/RelNotes-1.5.0.1.txt

@@ -1,42 +0,0 @@
-GIT v1.5.0.1 Release Notes
-==========================
-
-Fixes since v1.5.0
-------------------
-
-* Documentation updates
-
-  - Clarifications and corrections to 1.5.0 release notes.
-
-  - The main documentation did not link to git-remote documentation.
-
-  - Clarified introductory text of git-rebase documentation.
-
-  - Converted remaining mentions of update-index on Porcelain
-    documents to git-add/git-rm.
-
-  - Some i18n.* configuration variables were incorrectly
-    described as core.*; fixed.
-
-* Bugfixes
-
-  - git-add and git-update-index on a filesystem on which
-    executable bits are unreliable incorrectly reused st_mode
-    bits even when the path changed between symlink and regular
-    file.
-
-  - git-daemon marks the listening sockets with FD_CLOEXEC so
-    that it won't be leaked into the children.
-
-  - segfault from git-blame when the mandatory pathname
-    parameter was missing was fixed; usage() message is given
-    instead.
-
-  - git-rev-list did not read $GIT_DIR/config file, which means
-    that did not honor i18n.logoutputencoding correctly.
-
-* Tweaks
-
-  - sliding mmap() inefficiently mmaped the same region of a
-    packfile with an access pattern that used objects in the
-    reverse order.  This has been made more efficient.

Documentation/RelNotes-1.5.0.2.txt

@@ -1,65 +0,0 @@
-GIT v1.5.0.2 Release Notes
-==========================
-
-Fixes since v1.5.0.1
---------------------
-
-* Bugfixes
-
-  - Automated merge conflict handling when changes to symbolic
-    links conflicted were completely broken.  The merge-resolve
-    strategy created a regular file with conflict markers in it
-    in place of the symbolic link.  The default strategy,
-    merge-recursive was even more broken.  It removed the path
-    that was pointed at by the symbolic link.  Both of these
-    problems have been fixed.
-
-  - 'git diff maint master next' did not correctly give combined
-    diff across three trees.
-
-  - 'git fast-import' portability fix for Solaris.
-
-  - 'git show-ref --verify' without arguments did not error out
-    but segfaulted.
-
-  - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra
-    slashes after a/ and b/.
-
-  - 'git format-patch' produced too long filenames if the commit
-    message had too long line at the beginning.
-
-  - Running 'make all' and then without changing anything
-    running 'make install' still rebuilt some files.  This
-    was inconvenient when building as yourself and then
-    installing as root (especially problematic when the source
-    directory is on NFS and root is mapped to nobody).
-
-  - 'git-rerere' failed to deal with two unconflicted paths that
-    sorted next to each other.
-
-  - 'git-rerere' attempted to open(2) a symlink and failed if
-    there was a conflict.  Since a conflicting change to a
-    symlink would not benefit from rerere anyway, the command
-    now ignores conflicting changes to symlinks.
-
-  - 'git-repack' did not like to pass more than 64 arguments
-    internally to underlying 'rev-list' logic, which made it
-    impossible to repack after accumulating many (small) packs
-    in the repository.
-
-  - 'git-diff' to review the combined diff during a conflicted
-    merge were not reading the working tree version correctly
-    when changes to a symbolic link conflicted.  It should have
-    read the data using readlink(2) but read from the regular
-    file the symbolic link pointed at.
-
-  - 'git-remote' did not like period in a remote's name.
-
-* Documentation updates
-
-  - added and clarified core.bare, core.legacyheaders configurations.
-
-  - updated "git-clone --depth" documentation.
-
-
-* Assorted git-gui fixes.

Documentation/RelNotes-1.5.0.3.txt

@@ -1,58 +0,0 @@
-GIT v1.5.0.3 Release Notes
-==========================
-
-Fixes since v1.5.0.2
---------------------
-
-* Bugfixes
-
-  - 'git.el' honors the commit coding system from the configuration.
-
-  - 'blameview' in contrib/ correctly digs deeper when a line is
-    clicked.
-
-  - 'http-push' correctly makes sure the remote side has leading
-    path.  Earlier it started in the middle of the path, and
-    incorrectly.
-
-  - 'git-merge' did not exit with non-zero status when the
-    working tree was dirty and cannot fast forward.  It does
-    now.
-
-  - 'cvsexportcommit' does not lose yet-to-be-used message file.
-
-  - int-vs-size_t typefix when running combined diff on files
-    over 2GB long.
-
-  - 'git apply --whitespace=strip' should not touch unmodified
-    lines.
-
-  - 'git-mailinfo' choke when a logical header line was too long.
-
-  - 'git show A..B' did not error out.  Negative ref ("not A" in
-    this example) does not make sense for the purpose of the
-    command, so now it errors out.
-
-  - 'git fmt-merge-msg --file' without file parameter did not
-    correctly error out.
-
-  - 'git archimport' barfed upon encountering a commit without
-    summary.
-
-  - 'git index-pack' did not protect itself from getting a short
-    read out of pread(2).
-
-  - 'git http-push' had a few buffer overruns.
-
-  - Build dependency fixes to rebuild fetch.o when other headers
-    change.
-
-* Documentation updates
-
-  - user-manual updates.
-
-  - Options to 'git remote add' were described insufficiently.
-
-  - Configuration format.suffix was not documented.
-
-  - Other formatting and spelling fixes.

Documentation/RelNotes-1.5.0.4.txt

@@ -1,22 +0,0 @@
-GIT v1.5.0.4 Release Notes
-==========================
-
-Fixes since v1.5.0.3
---------------------
-
-* Bugfixes
-
-  - git.el does not add duplicate sign-off lines.
-
-  - git-commit shows the full stat of the resulting commit, not
-    just about the files in the current directory, when run from
-    a subdirectory.
-
-  - "git-checkout -m '@{8 hours ago}'" had a funny failure from
-    eval; fixed.
-
-  - git-gui updates.
-
-* Documentation updates
-
-* User manual updates

Documentation/RelNotes-1.5.0.5.txt

@@ -1,26 +0,0 @@
-GIT v1.5.0.5 Release Notes
-==========================
-
-Fixes since v1.5.0.3
---------------------
-
-* Bugfixes
-
-  - git-merge (hence git-pull) did not refuse fast-forwarding
-    when the working tree had local changes that would have
-    conflicted with it.
-
-  - git.el does not add duplicate sign-off lines.
-
-  - git-commit shows the full stat of the resulting commit, not
-    just about the files in the current directory, when run from
-    a subdirectory.
-
-  - "git-checkout -m '@{8 hours ago}'" had a funny failure from
-    eval; fixed.
-
-  - git-gui updates.
-
-* Documentation updates
-
-* User manual updates

Documentation/RelNotes-1.5.0.6.txt

@@ -1,21 +0,0 @@
-GIT v1.5.0.6 Release Notes
-==========================
-
-Fixes since v1.5.0.5
---------------------
-
-* Bugfixes
-
-  - a handful small fixes to gitweb.
-
-  - build procedure for user-manual is fixed not to require locally
-    installed stylesheets.
-
-  - "git commit $paths" on paths whose earlier contents were
-    already updated in the index were failing out.
-
-* Documentation
-
-  - user-manual has better cross references.
-
-  - gitweb installation/deployment procedure is now documented.

Documentation/RelNotes-1.5.0.7.txt

@@ -1,18 +0,0 @@
-GIT v1.5.0.7 Release Notes
-==========================
-
-Fixes since v1.5.0.6
---------------------
-
-* Bugfixes
-
-  - git-upload-pack failed to close unused pipe ends, resulting
-    in many zombies to hang around.
-
-  - git-rerere was recording the contents of earlier hunks
-    duplicated in later hunks.  This prevented resolving the same
-    conflict when performing the same merge the other way around.
-
-* Documentation
-
-  - a few documentation fixes from Debian package maintainer.

Documentation/RelNotes-1.5.0.txt

@@ -1,469 +0,0 @@
-GIT v1.5.0 Release Notes
-========================
-
-Old news
---------
-
-This section is for people who are upgrading from ancient
-versions of git.  Although all of the changes in this section
-happened before the current v1.4.4 release, they are summarized
-here in the v1.5.0 release notes for people who skipped earlier
-versions.
-
-As of git v1.5.0 there are some optional features that changes
-the repository to allow data to be stored and transferred more
-efficiently.  These features are not enabled by default, as they
-will make the repository unusable with older versions of git.
-Specifically, the available options are:
-
- - There is a configuration variable core.legacyheaders that
-   changes the format of loose objects so that they are more
-   efficient to pack and to send out of the repository over git
-   native protocol, since v1.4.2.  However, loose objects
-   written in the new format cannot be read by git older than
-   that version; people fetching from your repository using
-   older clients over dumb transports (e.g. http) using older
-   versions of git will also be affected.
-
-   To let git use the new loose object format, you have to
-   set core.legacyheaders to false.
-
- - Since v1.4.3, configuration repack.usedeltabaseoffset allows
-   packfile to be created in more space efficient format, which
-   cannot be read by git older than that version.
-
-   To let git use the new format for packfiles, you have to
-   set repack.usedeltabaseoffset to true.
-
-The above two new features are not enabled by default and you
-have to explicitly ask for them, because they make repositories
-unreadable by older versions of git, and in v1.5.0 we still do
-not enable them by default for the same reason.  We will change
-this default probably 1 year after 1.4.2's release, when it is
-reasonable to expect everybody to have new enough version of
-git.
-
- - 'git pack-refs' appeared in v1.4.4; this command allows tags
-   to be accessed much more efficiently than the traditional
-   'one-file-per-tag' format.  Older git-native clients can
-   still fetch from a repository that packed and pruned refs
-   (the server side needs to run the up-to-date version of git),
-   but older dumb transports cannot.  Packing of refs is done by
-   an explicit user action, either by use of "git pack-refs
-   --prune" command or by use of "git gc" command.
-
- - 'git -p' to paginate anything -- many commands do pagination
-   by default on a tty.  Introduced between v1.4.1 and v1.4.2;
-   this may surprise old timers.
-
- - 'git archive' superseded 'git tar-tree' in v1.4.3;
-
- - 'git cvsserver' was new invention in v1.3.0;
-
- - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
-   seriously enhanced during v1.4.0 timeperiod.
-
- - 'gitweb' became part of git.git during v1.4.0 timeperiod and
-   seriously modified since then.
-
- - reflog is an v1.4.0 invention.  This allows you to name a
-   revision that a branch used to be at (e.g. "git diff
-   master@{yesterday} master" allows you to see changes since
-   yesterday's tip of the branch).
-
-
-Updates in v1.5.0 since v1.4.4 series
--------------------------------------
-
-* Index manipulation
-
- - git-add is to add contents to the index (aka "staging area"
-   for the next commit), whether the file the contents happen to
-   be is an existing one or a newly created one.
-
- - git-add without any argument does not add everything
-   anymore.  Use 'git-add .' instead.  Also you can add
-   otherwise ignored files with an -f option.
-
- - git-add tries to be more friendly to users by offering an
-   interactive mode ("git-add -i").
-
- - git-commit <path> used to refuse to commit if <path> was
-   different between HEAD and the index (i.e. update-index was
-   used on it earlier).  This check was removed.
-
- - git-rm is much saner and safer.  It is used to remove paths
-   from both the index file and the working tree, and makes sure
-   you are not losing any local modification before doing so.
-
- - git-reset <tree> <paths>... can be used to revert index
-   entries for selected paths.
-
- - git-update-index is much less visible.  Many suggestions to
-   use the command in git output and documentation have now been
-   replaced by simpler commands such as "git add" or "git rm".
-
-
-* Repository layout and objects transfer
-
- - The data for origin repository is stored in the configuration
-   file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
-   created clones.  The latter is still supported and there is
-   no need to convert your existing repository if you are
-   already comfortable with your workflow with the layout.
-
- - git-clone always uses what is known as "separate remote"
-   layout for a newly created repository with a working tree.
-
-   A repository with the separate remote layout starts with only
-   one default branch, 'master', to be used for your own
-   development.  Unlike the traditional layout that copied all
-   the upstream branches into your branch namespace (while
-   renaming their 'master' to your 'origin'), the new layout
-   puts upstream branches into local "remote-tracking branches"
-   with their own namespace. These can be referenced with names
-   such as "origin/$upstream_branch_name" and are stored in
-   .git/refs/remotes rather than .git/refs/heads where normal
-   branches are stored.
-
-   This layout keeps your own branch namespace less cluttered,
-   avoids name collision with your upstream, makes it possible
-   to automatically track new branches created at the remote
-   after you clone from it, and makes it easier to interact with
-   more than one remote repository (you can use "git remote" to
-   add other repositories to track).  There might be some
-   surprises:
-
-   * 'git branch' does not show the remote tracking branches.
-     It only lists your own branches.  Use '-r' option to view
-     the tracking branches.
-
-   * If you are forking off of a branch obtained from the
-     upstream, you would have done something like 'git branch
-     my-next next', because traditional layout dropped the
-     tracking branch 'next' into your own branch namespace.
-     With the separate remote layout, you say 'git branch next
-     origin/next', which allows you to use the matching name
-     'next' for your own branch.  It also allows you to track a
-     remote other than 'origin' (i.e. where you initially cloned
-     from) and fork off of a branch from there the same way
-     (e.g. "git branch mingw j6t/master").
-
-   Repositories initialized with the traditional layout continue
-   to work.
-
- - New branches that appear on the origin side after a clone is
-   made are also tracked automatically.  This is done with an
-   wildcard refspec "refs/heads/*:refs/remotes/origin/*", which
-   older git does not understand, so if you clone with 1.5.0,
-   you would need to downgrade remote.*.fetch in the
-   configuration file to specify each branch you are interested
-   in individually if you plan to fetch into the repository with
-   older versions of git (but why would you?).
-
- - Similarly, wildcard refspec "refs/heads/*:refs/remotes/me/*"
-   can be given to "git-push" command to update the tracking
-   branches that is used to track the repository you are pushing
-   from on the remote side.
-
- - git-branch and git-show-branch know remote tracking branches
-   (use the command line switch "-r" to list only tracked branches).
-
- - git-push can now be used to delete a remote branch or a tag.
-   This requires the updated git on the remote side (use "git
-   push <remote> :refs/heads/<branch>" to delete "branch").
-
- - git-push more aggressively keeps the transferred objects
-   packed.  Earlier we recommended to monitor amount of loose
-   objects and repack regularly, but you should repack when you
-   accumulated too many small packs this way as well.  Updated
-   git-count-objects helps you with this.
-
- - git-fetch also more aggressively keeps the transferred objects
-   packed.  This behavior of git-push and git-fetch can be
-   tweaked with a single configuration transfer.unpacklimit (but
-   usually there should not be any need for a user to tweak it).
-
- - A new command, git-remote, can help you manage your remote
-   tracking branch definitions.
-
- - You may need to specify explicit paths for upload-pack and/or
-   receive-pack due to your ssh daemon configuration on the
-   other end.  This can now be done via remote.*.uploadpack and
-   remote.*.receivepack configuration.
-
-
-* Bare repositories
-
- - Certain commands change their behavior in a bare repository
-   (i.e. a repository without associated working tree).  We use
-   a fairly conservative heuristic (if $GIT_DIR is ".git", or
-   ends with "/.git", the repository is not bare) to decide if a
-   repository is bare, but "core.bare" configuration variable
-   can be used to override the heuristic when it misidentifies
-   your repository.
-
- - git-fetch used to complain updating the current branch but
-   this is now allowed for a bare repository.  So is the use of
-   'git-branch -f' to update the current branch.
-
- - Porcelain-ish commands that require a working tree refuses to
-   work in a bare repository.
-
-
-* Reflog
-
- - Reflog records the history from the view point of the local
-   repository. In other words, regardless of the real history,
-   the reflog shows the history as seen by one particular
-   repository (this enables you to ask "what was the current
-   revision in _this_ repository, yesterday at 1pm?").  This
-   facility is enabled by default for repositories with working
-   trees, and can be accessed with the "branch@{time}" and
-   "branch@{Nth}" notation.
-
- - "git show-branch" learned showing the reflog data with the
-   new -g option.  "git log" has -g option to view reflog
-   entries in a more verbose manner.
-
- - git-branch knows how to rename branches and moves existing
-   reflog data from the old branch to the new one.
-
- - In addition to the reflog support in v1.4.4 series, HEAD
-   reference maintains its own log.  "HEAD@{5.minutes.ago}"
-   means the commit you were at 5 minutes ago, which takes
-   branch switching into account.  If you want to know where the
-   tip of your current branch was at 5 minutes ago, you need to
-   explicitly say its name (e.g. "master@{5.minutes.ago}") or
-   omit the refname altogether i.e. "@{5.minutes.ago}".
-
- - The commits referred to by reflog entries are now protected
-   against pruning.  The new command "git reflog expire" can be
-   used to truncate older reflog entries and entries that refer
-   to commits that have been pruned away previously with older
-   versions of git.
-
-   Existing repositories that have been using reflog may get
-   complaints from fsck-objects and may not be able to run
-   git-repack, if you had run git-prune from older git; please
-   run "git reflog expire --stale-fix --all" first to remove
-   reflog entries that refer to commits that are no longer in
-   the repository when that happens.
-
-
-* Crufts removal
-
- - We used to say "old commits are retrievable using reflog and
-   'master@{yesterday}' syntax as long as you haven't run
-   git-prune".  We no longer have to say the latter half of the
-   above sentence, as git-prune does not remove things reachable
-   from reflog entries.
-
- - There is a toplevel garbage collector script, 'git-gc', that
-   runs periodic cleanup functions, including 'git-repack -a -d',
-   'git-reflog expire', 'git-pack-refs --prune', and 'git-rerere
-   gc'.
-
- - The output from fsck ("fsck-objects" is called just "fsck"
-   now, but the old name continues to work) was needlessly
-   alarming in that it warned missing objects that are reachable
-   only from dangling objects.  This has been corrected and the
-   output is much more useful.
-
-
-* Detached HEAD
-
- - You can use 'git-checkout' to check out an arbitrary revision
-   or a tag as well, instead of named branches.  This will
-   dissociate your HEAD from the branch you are currently on.
-
-   A typical use of this feature is to "look around".  E.g.
-
-	$ git checkout v2.6.16
-	... compile, test, etc.
-	$ git checkout v2.6.17
-	... compile, test, etc.
-
- - After detaching your HEAD, you can go back to an existing
-   branch with usual "git checkout $branch".  Also you can
-   start a new branch using "git checkout -b $newbranch" to
-   start a new branch at that commit.
-
- - You can even pull from other repositories, make merges and
-   commits while your HEAD is detached.  Also you can use "git
-   reset" to jump to arbitrary commit, while still keeping your
-   HEAD detached.
-
-   Remember that a detached state is volatile, i.e. it will be forgotten
-   as soon as you move away from it with the checkout or reset command,
-   unless a branch is created from it as mentioned above.  It is also
-   possible to rescue a lost detached state from the HEAD reflog.
-
-
-* Packed refs
-
- - Repositories with hundreds of tags have been paying large
-   overhead, both in storage and in runtime, due to the
-   traditional one-ref-per-file format.  A new command,
-   git-pack-refs, can be used to "pack" them in more efficient
-   representation (you can let git-gc do this for you).
-
- - Clones and fetches over dumb transports are now aware of
-   packed refs and can download from repositories that use
-   them.
-
-
-* Configuration
-
- - configuration related to color setting are consolidated under
-   color.* namespace (older diff.color.*, status.color.* are
-   still supported).
-
- - 'git-repo-config' command is accessible as 'git-config' now.
-
-
-* Updated features
-
- - git-describe uses better criteria to pick a base ref.  It
-   used to pick the one with the newest timestamp, but now it
-   picks the one that is topologically the closest (that is,
-   among ancestors of commit C, the ref T that has the shortest
-   output from "git-rev-list T..C" is chosen).
-
- - git-describe gives the number of commits since the base ref
-   between the refname and the hash suffix.  E.g. the commit one
-   before v2.6.20-rc6 in the kernel repository is:
-
-	v2.6.20-rc5-306-ga21b069
-
-   which tells you that its object name begins with a21b069,
-   v2.6.20-rc5 is an ancestor of it (meaning, the commit
-   contains everything -rc5 has), and there are 306 commits
-   since v2.6.20-rc5.
-
- - git-describe with --abbrev=0 can be used to show only the
-   name of the base ref.
-
- - git-blame learned a new option, --incremental, that tells it
-   to output the blames as they are assigned.  A sample script
-   to use it is also included as contrib/blameview.
-
- - git-blame starts annotating from the working tree by default.
-
-
-* Less external dependency
-
- - We no longer require the "merge" program from the RCS suite.
-   All 3-way file-level merges are now done internally.
-
- - The original implementation of git-merge-recursive which was
-   in Python has been removed; we have a C implementation of it
-   now.
-
- - git-shortlog is no longer a Perl script.  It no longer
-   requires output piped from git-log; it can accept revision
-   parameters directly on the command line.
-
-
-* I18n
-
- - We have always encouraged the commit message to be encoded in
-   UTF-8, but the users are allowed to use legacy encoding as
-   appropriate for their projects.  This will continue to be the
-   case.  However, a non UTF-8 commit encoding _must_ be
-   explicitly set with i18n.commitencoding in the repository
-   where a commit is made; otherwise git-commit-tree will
-   complain if the log message does not look like a valid UTF-8
-   string.
-
- - The value of i18n.commitencoding in the originating
-   repository is recorded in the commit object on the "encoding"
-   header, if it is not UTF-8.  git-log and friends notice this,
-   and reencodes the message to the log output encoding when
-   displaying, if they are different.  The log output encoding
-   is determined by "git log --encoding=<encoding>",
-   i18n.logoutputencoding configuration, or i18n.commitencoding
-   configuration, in the decreasing order of preference, and
-   defaults to UTF-8.
-
- - Tools for e-mailed patch application now default to -u
-   behavior; i.e. it always re-codes from the e-mailed encoding
-   to the encoding specified with i18n.commitencoding.  This
-   unfortunately forces projects that have happily been using a
-   legacy encoding without setting i18n.commitencoding to set
-   the configuration, but taken with other improvement, please
-   excuse us for this very minor one-time inconvenience.
-
-
-* e-mailed patches
-
- - See the above I18n section.
-
- - git-format-patch now enables --binary without being asked.
-   git-am does _not_ default to it, as sending binary patch via
-   e-mail is unusual and is harder to review than textual
-   patches and it is prudent to require the person who is
-   applying the patch to explicitly ask for it.
-
- - The default suffix for git-format-patch output is now ".patch",
-   not ".txt".  This can be changed with --suffix=.txt option,
-   or setting the config variable "format.suffix" to ".txt".
-
-
-* Foreign SCM interfaces
-
- - git-svn now requires the Perl SVN:: libraries, the
-   command-line backend was too slow and limited.
-
- - the 'commit' subcommand of git-svn has been renamed to
-   'set-tree', and 'dcommit' is the recommended replacement for
-   day-to-day work.
-
- - git fast-import backend.
-
-
-* User support
-
- - Quite a lot of documentation updates.
-
- - Bash completion scripts have been updated heavily.
-
- - Better error messages for often used Porcelainish commands.
-
- - Git GUI.  This is a simple Tk based graphical interface for
-   common Git operations.
-
-
-* Sliding mmap
-
- - We used to assume that we can mmap the whole packfile while
-   in use, but with a large project this consumes huge virtual
-   memory space and truly huge ones would not fit in the
-   userland address space on 32-bit platforms.  We now mmap huge
-   packfile in pieces to avoid this problem.
-
-
-* Shallow clones
-
- - There is a partial support for 'shallow' repositories that
-   keeps only recent history.  A 'shallow clone' is created by
-   specifying how deep that truncated history should be
-   (e.g. "git clone --depth 5 git://some.where/repo.git").
-
-   Currently a shallow repository has number of limitations:
-
-   - Cloning and fetching _from_ a shallow clone are not
-     supported (nor tested -- so they might work by accident but
-     they are not expected to).
-
-   - Pushing from nor into a shallow clone are not expected to
-     work.
-
-   - Merging inside a shallow repository would work as long as a
-     merge base is found in the recent history, but otherwise it
-     will be like merging unrelated histories and may result in
-     huge conflicts.
-
-   but this would be more than adequate for people who want to
-   look at near the tip of a big project with a deep history and
-   send patches in e-mail format.

Documentation/RelNotes-1.5.1.1.txt

@@ -1,65 +0,0 @@
-GIT v1.5.1.1 Release Notes
-==========================
-
-Fixes since v1.5.1
-------------------
-
-* Documentation updates
-
-  - The --left-right option of rev-list and friends is documented.
-
-  - The documentation for cvsimport has been majorly improved.
-
-  - "git-show-ref --exclude-existing" was documented.
-
-* Bugfixes
-
-  - The implementation of -p option in "git cvsexportcommit" had
-    the meaning of -C (context reduction) option wrong, and
-    loosened the context requirements when it was told to be
-    strict.
-
-  - "git cvsserver" did not behave like the real cvsserver when
-    client side removed a file from the working tree without
-    doing anything else on the path.  In such a case, it should
-    restore it from the checked out revision.
-
-  - "git fsck" issued an alarming error message on detached
-    HEAD.  It is not an error since at least 1.5.0.
-
-  - "git send-email" produced of References header of unbounded length;
-    fixed this with line-folding.
-
-  - "git archive" to download from remote site should not
-    require you to be in a git repository, but it incorrectly
-    did.
-
-  - "git apply" ignored -p<n> for "diff --git" formatted
-    patches.
-
-  - "git rerere" recorded a conflict that had one side empty
-    (the other side adds) incorrectly; this made merging in the
-    other direction fail to use previously recorded resolution.
-
-  - t4200 test was broken where "wc -l" pads its output with
-    spaces.
-
-  - "git branch -m old new" to rename branch did not work
-    without a configuration file in ".git/config".
-
-  - The sample hook for notification e-mail was misnamed.
-
-  - gitweb did not show type-changing patch correctly in the
-    blobdiff view.
-
-  - git-svn did not error out with incorrect command line options.
-
-  - git-svn fell into an infinite loop when insanely long commit
-    message was found.
-
-  - git-svn dcommit and rebase was confused by patches that were
-    merged from another branch that is managed by git-svn.
-
-  - git-svn used to get confused when globbing remote branch/tag
-    spec (e.g. "branches = proj/branches/*:refs/remotes/origin/*")
-    is used and there was a plain file that matched the glob.

Documentation/RelNotes-1.5.1.2.txt

@@ -1,50 +0,0 @@
-GIT v1.5.1.2 Release Notes
-==========================
-
-Fixes since v1.5.1.1
---------------------
-
-* Bugfixes
-
-  - "git clone" over http from a repository that has lost the
-    loose refs by running "git pack-refs" were broken (a code to
-    deal with this was added to "git fetch" in v1.5.0, but it
-    was missing from "git clone").
-
-  - "git diff a/ b/" incorrectly fell in "diff between two
-    filesystem objects" codepath, when the user most likely
-    wanted to limit the extent of output to two tracked
-    directories.
-
-  - git-quiltimport had the same bug as we fixed for
-    git-applymbox in v1.5.1.1 -- it gave an alarming "did not
-    have any patch" message (but did not actually fail and was
-    harmless).
-
-  - various git-svn fixes.
-
-  - Sample update hook incorrectly always refused requests to
-    delete branches through push.
-
-  - git-blame on a very long working tree path had buffer
-    overrun problem.
-
-  - git-apply did not like to be fed two patches in a row that created
-    and then modified the same file.
-
-  - git-svn was confused when a non-project was stored directly under
-    trunk/, branches/ and tags/.
-
-  - git-svn wants the Error.pm module that was at least as new
-    as what we ship as part of git; install ours in our private
-    installation location if the one on the system is older.
-
-  - An earlier update to command line integer parameter parser was
-    botched and made 'update-index --cacheinfo' completely useless.
-
-
-* Documentation updates
-
-  - Various documentation updates from J. Bruce Fields, Frank
-    Lichtenheld, Alex Riesen and others.  Andrew Ruder started a
-    war on undocumented options.

Documentation/RelNotes-1.5.1.3.txt

@@ -1,45 +0,0 @@
-GIT v1.5.1.3 Release Notes
-==========================
-
-Fixes since v1.5.1.2
---------------------
-
-* Bugfixes
-
-  - git-add tried to optimize by finding common leading
-    directories across its arguments but botched, causing very
-    confused behaviour.
-
-  - unofficial rpm.spec file shipped with git was letting
-    ETC_GITCONFIG set to /usr/etc/gitconfig.  Tweak the official
-    Makefile to make it harder for distro people to make the
-    same mistake, by setting the variable to /etc/gitconfig if
-    prefix is set to /usr.
-
-  - git-svn inconsistently stripped away username from the URL
-    only when svnsync_props was in use.
-
-  - git-svn got confused when handling symlinks on Mac OS.
-
-  - git-send-email was not quoting recipient names that have
-    period '.' in them.  Also it did not allow overriding
-    envelope sender, which made it impossible to send patches to
-    certain subscriber-only lists.
-
-  - built-in write_tree() routine had a sequence that renamed a
-    file that is still open, which some systems did not like.
-
-  - when memory is very tight, sliding mmap code to read
-    packfiles incorrectly closed the fd that was still being
-    used to read the pack.
-
-  - import-tars contributed front-end for fastimport was passing
-    wrong directory modes without checking.
-
-  - git-fastimport trusted its input too much and allowed to
-    create corrupt tree objects with entries without a name.
-
-  - git-fetch needlessly barfed when too long reflog action
-    description was given by the caller.
-
-Also contains various documentation updates.

Documentation/RelNotes-1.5.1.4.txt

@@ -1,30 +0,0 @@
-GIT v1.5.1.4 Release Notes
-==========================
-
-Fixes since v1.5.1.3
---------------------
-
-* Bugfixes
-
-  - "git-http-fetch" did not work around a bug in libcurl
-    earlier than 7.16 (curl_multi_remove_handle() was broken).
-
-  - "git cvsserver" handles a file that was once removed and
-    then added again correctly.
-
-  - import-tars script (in contrib/) handles GNU tar archives
-    that contain pathnames longer than 100 bytes (long-link
-    extension) correctly.
-
-  - xdelta test program did not build correctly.
-
-  - gitweb sometimes tried incorrectly to apply function to
-    decode utf8 twice, resulting in corrupt output.
-
-  - "git blame -C" mishandled text at the end of a group of
-    lines.
-
-  - "git log/rev-list --boundary" did not produce output
-    correctly without --left-right option.
-
-  - Many documentation updates.

Documentation/RelNotes-1.5.1.5.txt

@@ -1,42 +0,0 @@
-GIT v1.5.1.5 Release Notes
-==========================
-
-Fixes since v1.5.1.4
---------------------
-
-* Bugfixes
-
-  - git-send-email did not understand aliases file for mutt, which
-    allows leading whitespaces.
-
-  - git-format-patch emitted Content-Type and Content-Transfer-Encoding
-    headers for non ASCII contents, but failed to add MIME-Version.
-
-  - git-name-rev had a buffer overrun with a deep history.
-
-  - contributed script import-tars did not get the directory in
-    tar archives interpreted correctly.
-
-  - git-svn was reported to segfault for many people on list and
-    #git; hopefully this has been fixed.
-
-  - "git-svn clone" does not try to minimize the URL
-    (i.e. connect to higher level hierarchy) by default, as this
-    can prevent clone to fail if only part of the repository
-    (e.g. 'trunk') is open to public.
-
-  - "git checkout branch^0" did not detach the head when you are
-    already on 'branch'; backported the fix from the 'master'.
-
-  - "git-config section.var" did not correctly work when
-    existing configuration file had both [section] and [section "name"]
-    next to each other.
-
-  - "git clone ../other-directory" was fooled if the current
-    directory $PWD points at is a symbolic link.
-
-  - (build) tree_entry_extract() function was both static inline
-    and extern, which caused trouble compiling with Forte12
-    compilers on Sun.
-
-  - Many many documentation fixes and updates.

Documentation/RelNotes-1.5.1.6.txt

@@ -1,45 +0,0 @@
-GIT v1.5.1.6 Release Notes
-==========================
-
-Fixes since v1.5.1.4
---------------------
-
-* Bugfixes
-
-  - git-send-email did not understand aliases file for mutt, which
-    allows leading whitespaces.
-
-  - git-format-patch emitted Content-Type and Content-Transfer-Encoding
-    headers for non ASCII contents, but failed to add MIME-Version.
-
-  - git-name-rev had a buffer overrun with a deep history.
-
-  - contributed script import-tars did not get the directory in
-    tar archives interpreted correctly.
-
-  - git-svn was reported to segfault for many people on list and
-    #git; hopefully this has been fixed.
-
-  - git-svn also had a bug to crash svnserve by sending a bad
-    sequence of requests.
-
-  - "git-svn clone" does not try to minimize the URL
-    (i.e. connect to higher level hierarchy) by default, as this
-    can prevent clone to fail if only part of the repository
-    (e.g. 'trunk') is open to public.
-
-  - "git checkout branch^0" did not detach the head when you are
-    already on 'branch'; backported the fix from the 'master'.
-
-  - "git-config section.var" did not correctly work when
-    existing configuration file had both [section] and [section "name"]
-    next to each other.
-
-  - "git clone ../other-directory" was fooled if the current
-    directory $PWD points at is a symbolic link.
-
-  - (build) tree_entry_extract() function was both static inline
-    and extern, which caused trouble compiling with Forte12
-    compilers on Sun.
-
-  - Many many documentation fixes and updates.

Documentation/RelNotes-1.5.1.txt

@@ -1,371 +0,0 @@
-GIT v1.5.1 Release Notes
-========================
-
-Updates since v1.5.0
---------------------
-
-* Deprecated commands and options.
-
-  - git-diff-stages and git-resolve have been removed.
-
-* New commands and options.
-
-  - "git log" and friends take --reverse, which instructs them
-    to give their output in the order opposite from their usual.
-    They typically output from new to old, but with this option
-    their output would read from old to new.  "git shortlog"
-    usually lists older commits first, but with this option,
-    they are shown from new to old.
-
-  - "git log --pretty=format:<string>" to allow more flexible
-    custom log output.
-
-  - "git diff" learned --ignore-space-at-eol.  This is a weaker
-    form of --ignore-space-change.
-
-  - "git diff --no-index pathA pathB" can be used as diff
-    replacement with git specific enhancements.
-
-  - "git diff --no-index" can read from '-' (standard input).
-
-  - "git diff" also learned --exit-code to exit with non-zero
-    status when it found differences.  In the future we might
-    want to make this the default but that would be a rather big
-    backward incompatible change; it will stay as an option for
-    now.
-
-  - "git diff --quiet" is --exit-code with output turned off,
-    meant for scripted use to quickly determine if there is any
-    tree-level difference.
-
-  - Textual patch generation with "git diff" without -w/-b
-    option has been significantly optimized.  "git blame" got
-    faster because of the same change.
-
-  - "git log" and "git rev-list" has been optimized
-    significantly when they are used with pathspecs.
-
-  - "git branch --track" can be used to set up configuration
-    variables to help it easier to base your work on branches
-    you track from a remote site.
-
-  - "git format-patch --attach" now emits attachments.  Use
-    --inline to get an inlined multipart/mixed.
-
-  - "git name-rev" learned --refs=<pattern>, to limit the tags
-    used for naming the given revisions only to the ones
-    matching the given pattern.
-
-  - "git remote update" is to run "git fetch" for defined remotes
-    to update tracking branches.
-
-  - "git cvsimport" can now take '-d' to talk with a CVS
-    repository different from what are recorded in CVS/Root
-    (overriding it with environment CVSROOT does not work).
-
-  - "git bundle" can help sneaker-netting your changes between
-    repositories.
-
-  - "git mergetool" can help 3-way file-level conflict
-    resolution with your favorite graphical merge tools.
-
-  - A new configuration "core.symlinks" can be used to disable
-    symlinks on filesystems that do not support them; they are
-    checked out as regular files instead.
-
-  - You can name a commit object with its first line of the
-    message.  The syntax to use is ':/message text'.  E.g.
-
-    $ git show ":/object name: introduce ':/<oneline prefix>' notation"
-
-    means the same thing as:
-
-    $ git show 28a4d940443806412effa246ecc7768a21553ec7
-
-  - "git bisect" learned a new command "run" that takes a script
-    to run after each revision is checked out to determine if it
-    is good or bad, to automate the bisection process.
-
-  - "git log" family learned a new traversal option --first-parent,
-    which does what the name suggests.
-
-
-* Updated behavior of existing commands.
-
-  - "git-merge-recursive" used to barf when there are more than
-    one common ancestors for the merge, and merging them had a
-    rename/rename conflict.  This has been fixed.
-
-  - "git fsck" does not barf on corrupt loose objects.
-
-  - "git rm" does not remove newly added files without -f.
-
-  - "git archimport" allows remapping when coming up with git
-    branch names from arch names.
-
-  - git-svn got almost a rewrite.
-
-  - core.autocrlf configuration, when set to 'true', makes git
-    to convert CRLF at the end of lines in text files to LF when
-    reading from the filesystem, and convert in reverse when
-    writing to the filesystem.  The variable can be set to
-    'input', in which case the conversion happens only while
-    reading from the filesystem but files are written out with
-    LF at the end of lines.  Currently, which paths to consider
-    'text' (i.e. be subjected to the autocrlf mechanism) is
-    decided purely based on the contents, but the plan is to
-    allow users to explicitly override this heuristic based on
-    paths.
-
-  - The behavior of 'git-apply', when run in a subdirectory,
-    without --index nor --cached were inconsistent with that of
-    the command with these options.  This was fixed to match the
-    behavior with --index.  A patch that is meant to be applied
-    with -p1 from the toplevel of the project tree can be
-    applied with any custom -p<n> option.  A patch that is not
-    relative to the toplevel needs to be applied with -p<n>
-    option with or without --index (or --cached).
-
-  - "git diff" outputs a trailing HT when pathnames have embedded
-    SP on +++/--- header lines, in order to help "GNU patch" to
-    parse its output.  "git apply" was already updated to accept
-    this modified output format since ce74618d (Sep 22, 2006).
-
-  - "git cvsserver" runs hooks/update and honors its exit status.
-
-  - "git cvsserver" can be told to send everything with -kb.
-
-  - "git diff --check" also honors the --color output option.
-
-  - "git name-rev" used to stress the fact that a ref is a tag too
-    much, by saying something like "v1.2.3^0~22".  It now says
-    "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does
-    not talk about an ancestor of the commit that is tagged, which
-    makes sense).
-
-  - "git rev-list --boundary" now shows boundary markers for the
-    commits omitted by --max-age and --max-count condition.
-
-  - The configuration mechanism now reads $(prefix)/etc/gitconfig.
-
-  - "git apply --verbose" shows what preimage lines were wanted
-    when it couldn't find them.
-
-  - "git status" in a read-only repository got a bit saner.
-
-  - "git fetch" (hence "git clone" and "git pull") are less
-    noisy when the output does not go to tty.
-
-  - "git fetch" between repositories with many refs were slow
-    even when there are not many changes that needed
-    transferring.  This has been sped up by partially rewriting
-    the heaviest parts in C.
-
-  - "git mailinfo" which splits an e-mail into a patch and the
-    meta-information was rewritten, thanks to Don Zickus.  It
-    handles nested multipart better.  The command was broken for
-    a brief period on 'master' branch since 1.5.0 but the
-    breakage is fixed now.
-
-  - send-email learned configurable bcc and chain-reply-to.
-
-  - "git remote show $remote" also talks about branches that
-    would be pushed if you run "git push remote".
-
-  - Using objects from packs is now seriously optimized by clever
-    use of a cache.  This should be most noticeable in git-log
-    family of commands that involve reading many tree objects.
-    In addition, traversing revisions while filtering changes
-    with pathspecs is made faster by terminating the comparison
-    between the trees as early as possible.
-
-
-* Hooks
-
-  - The part to send out notification e-mails was removed from
-    the sample update hook, as it was not an appropriate place
-    to do so.  The proper place to do this is the new post-receive
-    hook.  An example hook has been added to contrib/hooks/.
-
-
-* Others
-
-  - git-revert, git-gc and git-cherry-pick are now built-ins.
-
-Fixes since v1.5.0
-------------------
-
-These are all in v1.5.0.x series.
-
-* Documentation updates
-
-  - Clarifications and corrections to 1.5.0 release notes.
-
-  - The main documentation did not link to git-remote documentation.
-
-  - Clarified introductory text of git-rebase documentation.
-
-  - Converted remaining mentions of update-index on Porcelain
-    documents to git-add/git-rm.
-
-  - Some i18n.* configuration variables were incorrectly
-    described as core.*; fixed.
-
-  - added and clarified core.bare, core.legacyheaders configurations.
-
-  - updated "git-clone --depth" documentation.
-
-  - user-manual updates.
-
-  - Options to 'git remote add' were described insufficiently.
-
-  - Configuration format.suffix was not documented.
-
-  - Other formatting and spelling fixes.
-
-  - user-manual has better cross references.
-
-  - gitweb installation/deployment procedure is now documented.
-
-
-* Bugfixes
-
-  - git-upload-pack closes unused pipe ends; earlier this caused
-    many zombies to hang around.
-
-  - git-rerere was recording the contents of earlier hunks
-    duplicated in later hunks.  This prevented resolving the same
-    conflict when performing the same merge the other way around.
-
-  - git-add and git-update-index on a filesystem on which
-    executable bits are unreliable incorrectly reused st_mode
-    bits even when the path changed between symlink and regular
-    file.
-
-  - git-daemon marks the listening sockets with FD_CLOEXEC so
-    that it won't be leaked into the children.
-
-  - segfault from git-blame when the mandatory pathname
-    parameter was missing was fixed; usage() message is given
-    instead.
-
-  - git-rev-list did not read $GIT_DIR/config file, which means
-    that did not honor i18n.logoutputencoding correctly.
-
-  - Automated merge conflict handling when changes to symbolic
-    links conflicted were completely broken.  The merge-resolve
-    strategy created a regular file with conflict markers in it
-    in place of the symbolic link.  The default strategy,
-    merge-recursive was even more broken.  It removed the path
-    that was pointed at by the symbolic link.  Both of these
-    problems have been fixed.
-
-  - 'git diff maint master next' did not correctly give combined
-    diff across three trees.
-
-  - 'git fast-import' portability fix for Solaris.
-
-  - 'git show-ref --verify' without arguments did not error out
-    but segfaulted.
-
-  - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra
-    slashes after a/ and b/.
-
-  - 'git format-patch' produced too long filenames if the commit
-    message had too long line at the beginning.
-
-  - Running 'make all' and then without changing anything
-    running 'make install' still rebuilt some files.  This
-    was inconvenient when building as yourself and then
-    installing as root (especially problematic when the source
-    directory is on NFS and root is mapped to nobody).
-
-  - 'git-rerere' failed to deal with two unconflicted paths that
-    sorted next to each other.
-
-  - 'git-rerere' attempted to open(2) a symlink and failed if
-    there was a conflict.  Since a conflicting change to a
-    symlink would not benefit from rerere anyway, the command
-    now ignores conflicting changes to symlinks.
-
-  - 'git-repack' did not like to pass more than 64 arguments
-    internally to underlying 'rev-list' logic, which made it
-    impossible to repack after accumulating many (small) packs
-    in the repository.
-
-  - 'git-diff' to review the combined diff during a conflicted
-    merge were not reading the working tree version correctly
-    when changes to a symbolic link conflicted.  It should have
-    read the data using readlink(2) but read from the regular
-    file the symbolic link pointed at.
-
-  - 'git-remote' did not like period in a remote's name.
-
-  - 'git.el' honors the commit coding system from the configuration.
-
-  - 'blameview' in contrib/ correctly digs deeper when a line is
-    clicked.
-
-  - 'http-push' correctly makes sure the remote side has leading
-    path.  Earlier it started in the middle of the path, and
-    incorrectly.
-
-  - 'git-merge' did not exit with non-zero status when the
-    working tree was dirty and cannot fast forward.  It does
-    now.
-
-  - 'cvsexportcommit' does not lose yet-to-be-used message file.
-
-  - int-vs-size_t typefix when running combined diff on files
-    over 2GB long.
-
-  - 'git apply --whitespace=strip' should not touch unmodified
-    lines.
-
-  - 'git-mailinfo' choke when a logical header line was too long.
-
-  - 'git show A..B' did not error out.  Negative ref ("not A" in
-    this example) does not make sense for the purpose of the
-    command, so now it errors out.
-
-  - 'git fmt-merge-msg --file' without file parameter did not
-    correctly error out.
-
-  - 'git archimport' barfed upon encountering a commit without
-    summary.
-
-  - 'git index-pack' did not protect itself from getting a short
-    read out of pread(2).
-
-  - 'git http-push' had a few buffer overruns.
-
-  - Build dependency fixes to rebuild fetch.o when other headers
-    change.
-
-  - git.el does not add duplicate sign-off lines.
-
-  - git-commit shows the full stat of the resulting commit, not
-    just about the files in the current directory, when run from
-    a subdirectory.
-
-  - "git-checkout -m '@{8 hours ago}'" had a funny failure from
-    eval; fixed.
-
-  - git-merge (hence git-pull) did not refuse fast-forwarding
-    when the working tree had local changes that would have
-    conflicted with it.
-
-  - a handful small fixes to gitweb.
-
-  - build procedure for user-manual is fixed not to require locally
-    installed stylesheets.
-
-  - "git commit $paths" on paths whose earlier contents were
-    already updated in the index were failing out.
-
-
-* Tweaks
-
-  - sliding mmap() inefficiently mmaped the same region of a
-    packfile with an access pattern that used objects in the
-    reverse order.  This has been made more efficient.

Documentation/RelNotes-1.5.2.1.txt

@@ -1,53 +0,0 @@
-GIT v1.5.2.1 Release Notes
-==========================
-
-Fixes since v1.5.2
-------------------
-
-* Bugfixes
-
-  - Temporary files that are used when invoking external diff
-    programs did not tolerate a long TMPDIR.
-
-  - git-daemon did not notice when it could not write into its
-    pid file.
-
-  - git-status did not honor core.excludesFile configuration like
-    git-add did.
-
-  - git-annotate did not work from a subdirectory while
-    git-blame did.
-
-  - git-cvsserver should have disabled access to a repository
-    with "gitcvs.pserver.enabled = false" set even when
-    "gitcvs.enabled = true" was set at the same time.  It
-    didn't.
-
-  - git-cvsimport did not work correctly in a repository with
-    its branch heads were packed with pack-refs.
-
-  - ident unexpansion to squash "$Id: xxx $" that is in the
-    repository copy removed incorrect number of bytes.
-
-  - git-svn misbehaved when the subversion repository did not
-    provide MD5 checksums for files.
-
-  - git rebase (and git am) misbehaved on commits that have '\n'
-    (literally backslash and en, not a linefeed) in the title.
-
-  - code to decode base85 used in binary patches had one error
-    return codepath wrong.
-
-  - RFC2047 Q encoding output by git-format-patch used '_' for a
-    space, which is not understood by some programs.  It uses =20
-    which is safer.
-
-  - git-fastimport --import-marks was broken; fixed.
-
-  - A lot of documentation updates, clarifications and fixes.
-
---
-exec >/var/tmp/1
-O=v1.5.2-65-g996e2d6
-echo O=`git describe refs/heads/maint`
-git shortlog --no-merges $O..refs/heads/maint

Documentation/RelNotes-1.5.2.2.txt

@@ -1,61 +0,0 @@
-GIT v1.5.2.2 Release Notes
-==========================
-
-Fixes since v1.5.2.1
---------------------
-
-* Usability fix
-
-  - git-gui is shipped with its updated blame interface.  It is
-    rumored that the older one was not just unusable but was
-    active health hazard, but this one is actually pretty.
-    Please see for yourself.
-
-* Bugfixes
-
-  - "git checkout fubar" was utterly confused when there is a
-    branch fubar and a tag fubar at the same time.  It correctly
-    checks out the branch fubar now.
-
-  - "git clone /path/foo" to clone a local /path/foo.git
-    repository left an incorrect configuration.
-
-  - "git send-email" correctly unquotes RFC 2047 quoted names in
-    the patch-email before using their values.
-
-  - We did not accept number of seconds since epoch older than
-    year 2000 as a valid timestamp.  We now interpret positive
-    integers more than 8 digits as such, which allows us to
-    express timestamps more recent than March 1973.
-
-  - git-cvsimport did not work when you have GIT_DIR to point
-    your repository at a nonstandard location.
-
-  - Some systems (notably, Solaris) lack hstrerror() to make
-    h_errno human readable; prepare a replacement
-    implementation.
-
-  - .gitignore file listed git-core.spec but what we generate is
-    git.spec, and nobody noticed for a long time.
-
-  - "git-merge-recursive" does not try to run file level merge
-    on binary files.
-
-  - "git-branch --track" did not create tracking configuration
-    correctly when the branch name had slash in it.
-
-  - The email address of the user specified with user.email
-    configuration was overriden by EMAIL environment variable.
-
-  - The tree parser did not warn about tree entries with
-    nonsense file modes, and assumed they must be blobs.
-
-  - "git log -z" without any other request to generate diff still
-    invoked the diff machinery, wasting cycles.
-
-* Documentation
-
-  - Many updates to fix stale or missing documentation.
-
-  - Although our documentation was primarily meant to be formatted
-    with AsciiDoc7, formatting with AsciiDoc8 is supported better.

Documentation/RelNotes-1.5.2.3.txt

@@ -1,27 +0,0 @@
-GIT v1.5.2.3 Release Notes
-==========================
-
-Fixes since v1.5.2.2
---------------------
-
- * Bugfixes
-
-   - Version 2 pack index format was introduced in version 1.5.2
-     to support pack files that has offset that cannot be
-     represented in 32-bit.  The runtime code to validate such
-     an index mishandled such an index for an empty pack.
-
-   - Commit walkers (most notably, fetch over http protocol)
-     tried to traverse commit objects contained in trees (aka
-     subproject); they shouldn't.
-
-   - A build option NO_R_TO_GCC_LINKER was not explained in Makefile
-     comment correctly.
-
- * Documentation Fixes and Updates
-
-   - git-config --regexp was not documented properly.
-
-   - git-repack -a was not documented properly.
-
-   - git-remote -n was not documented properly.

Documentation/RelNotes-1.5.2.4.txt

@@ -1,28 +0,0 @@
-GIT v1.5.2.4 Release Notes
-==========================
-
-Fixes since v1.5.2.3
---------------------
-
- * Bugfixes
-
-   - "git-gui" bugfixes, including a handful fixes to run it
-     better on Cygwin/MSYS.
-
-   - "git checkout" failed to switch back and forth between
-     branches, one of which has "frotz -> xyzzy" symlink and
-     file "xyzzy/filfre", while the other one has a file
-     "frotz/filfre".
-
-   - "git prune" used to segfault upon seeing a commit that is
-     referred to by a tree object (aka "subproject").
-
-   - "git diff --name-status --no-index" mishandled an added file.
-
-   - "git apply --reverse --whitespace=warn" still complained
-     about whitespaces that a forward application would have
-     introduced.
-
- * Documentation Fixes and Updates
-
-   - A handful documentation updates.

Documentation/RelNotes-1.5.2.5.txt

@@ -1,30 +0,0 @@
-GIT v1.5.2.5 Release Notes
-==========================
-
-Fixes since v1.5.2.4
---------------------
-
- * Bugfixes
-
-   - "git add -u" had a serious data corruption problem in one
-     special case (when the changes to a subdirectory's files
-     consist only deletion of files).
-
-   - "git add -u <path>" did not work from a subdirectory.
-
-   - "git apply" left an empty directory after all its files are
-     renamed away.
-
-   - "git $anycmd foo/bar", when there is a file 'foo' in the
-     working tree, complained that "git $anycmd foo/bar --" form
-     should be used to disambiguate between revs and files,
-     which was completely bogus.
-
-   - "git checkout-index" and other commands that checks out
-     files to the work tree tried unlink(2) on directories,
-     which is a sane thing to do on sane systems, but not on
-     Solaris when you are root.
-
- * Documentation Fixes and Updates
-
-   - A handful documentation fixes.

Documentation/RelNotes-1.5.2.txt

@@ -1,197 +0,0 @@
-GIT v1.5.2 Release Notes
-========================
-
-Updates since v1.5.1
---------------------
-
-* Plumbing level superproject support.
-
-  You can include a subdirectory that has an independent git
-  repository in your index and tree objects of your project
-  ("superproject").  This plumbing (i.e. "core") level
-  superproject support explicitly excludes recursive behaviour.
-
-  The "subproject" entries in the index and trees of a superproject
-  are incompatible with older versions of git.  Experimenting with
-  the plumbing level support is encouraged, but be warned that
-  unless everybody in your project updates to this release or
-  later, using this feature would make your project
-  inaccessible by people with older versions of git.
-
-* Plumbing level gitattributes support.
-
-  The gitattributes mechanism allows you to add 'attributes' to
-  paths in your project, and affect the way certain git
-  operations work.  Currently you can influence if a path is
-  considered a binary or text (the former would be treated by
-  'git diff' not to produce textual output; the latter can go
-  through the line endings conversion process in repositories
-  with core.autocrlf set), expand and unexpand '$Id$' keyword
-  with blob object name, specify a custom 3-way merge driver,
-  and specify a custom diff driver.  You can also apply
-  arbitrary filter to contents on check-in/check-out codepath
-  but this feature is an extremely sharp-edged razor and needs
-  to be handled with caution (do not use it unless you
-  understand the earlier mailing list discussion on keyword
-  expansion).  These conversions apply when checking files in
-  or out, and exporting via git-archive.
-
-* The packfile format now optionally suports 64-bit index.
-
-  This release supports the "version 2" format of the .idx
-  file.  This is automatically enabled when a huge packfile
-  needs more than 32-bit to express offsets of objects in the
-  pack.
-
-* Comes with an updated git-gui 0.7.1
-
-* Updated gitweb:
-
-  - can show combined diff for merges;
-  - uses font size of user's preference, not hardcoded in pixels;
-  - can now 'grep';
-
-* New commands and options.
-
-  - "git bisect start" can optionally take a single bad commit and
-    zero or more good commits on the command line.
-
-  - "git shortlog" can optionally be told to wrap its output.
-
-  - "subtree" merge strategy allows another project to be merged in as
-    your subdirectory.
-
-  - "git format-patch" learned a new --subject-prefix=<string>
-    option, to override the built-in "[PATCH]".
-
-  - "git add -u" is a quick way to do the first stage of "git
-    commit -a" (i.e. update the index to match the working
-    tree); it obviously does not make a commit.
-
-  - "git clean" honors a new configuration, "clean.requireforce".  When
-    set to true, this makes "git clean" a no-op, preventing you
-    from losing files by typing "git clean" when you meant to
-    say "make clean".  You can still say "git clean -f" to
-    override this.
-
-  - "git log" family of commands learned --date={local,relative,default}
-    option.  --date=relative is synonym to the --relative-date.
-    --date=local gives the timestamp in local timezone.
-
-* Updated behavior of existing commands.
-
-  - When $GIT_COMMITTER_EMAIL or $GIT_AUTHOR_EMAIL is not set
-    but $EMAIL is set, the latter is used as a substitute.
-
-  - "git diff --stat" shows size of preimage and postimage blobs
-    for binary contents.  Earlier it only said "Bin".
-
-  - "git lost-found" shows stuff that are unreachable except
-    from reflogs.
-
-  - "git checkout branch^0" now detaches HEAD at the tip commit
-    on the named branch, instead of just switching to the
-    branch (use "git checkout branch" to switch to the branch,
-    as before).
-
-  - "git bisect next" can be used after giving only a bad commit
-    without giving a good one (this starts bisection half-way to
-    the root commit).  We used to refuse to operate without a
-    good and a bad commit.
-
-  - "git push", when pushing into more than one repository, does
-    not stop at the first error.
-
-  - "git archive" does not insist you to give --format parameter
-    anymore; it defaults to "tar".
-
-  - "git cvsserver" can use backends other than sqlite.
-
-  - "gitview" (in contrib/ section) learned to better support
-    "git-annotate".
-
-  - "git diff $commit1:$path2 $commit2:$path2" can now report
-    mode changes between the two blobs.
-
-  - Local "git fetch" from a repository whose object store is
-    one of the alternates (e.g. fetching from the origin in a
-    repository created with "git clone -l -s") avoids
-    downloading objects unnecessarily.
-
-  - "git blame" uses .mailmap to canonicalize the author name
-    just like "git shortlog" does.
-
-  - "git pack-objects" pays attention to pack.depth
-    configuration variable.
-
-  - "git cherry-pick" and "git revert" does not use .msg file in
-    the working tree to prepare commit message; instead it uses
-    $GIT_DIR/MERGE_MSG as other commands do.
-
-* Builds
-
-  - git-p4import has never been installed; now there is an
-    installation option to do so.
-
-  - gitk and git-gui can be configured out.
-
-  - Generated documentation pages automatically get version
-    information from GIT_VERSION.
-
-  - Parallel build with "make -j" descending into subdirectory
-    was fixed.
-
-* Performance Tweaks
-
-  - Optimized "git-rev-list --bisect" (hence "git-bisect").
-
-  - Optimized "git-add $path" in a large directory, most of
-    whose contents are ignored.
-
-  - Optimized "git-diff-tree" for reduced memory footprint.
-
-  - The recursive merge strategy updated a worktree file that
-    was changed identically in two branches, when one of them
-    renamed it.  We do not do that when there is no rename, so
-    match that behaviour.  This avoids excessive rebuilds.
-
-  - The default pack depth has been increased to 50, as the
-    recent addition of delta_base_cache makes deeper delta chains
-    much less expensive to access.  Depending on the project, it was
-    reported that this reduces the resulting pack file by 10%
-    or so.
-
-
-Fixes since v1.5.1
-------------------
-
-All of the fixes in v1.5.1 maintenance series are included in
-this release, unless otherwise noted.
-
-* Bugfixes
-
-  - Switching branches with "git checkout" refused to work when
-    a path changes from a file to a directory between the
-    current branch and the new branch, in order not to lose
-    possible local changes in the directory that is being turned
-    into a file with the switch.  We now allow such a branch
-    switch after making sure that there is no locally modified
-    file nor un-ignored file in the directory.  This has not
-    been backported to 1.5.1.x series, as it is rather an
-    intrusive change.
-
-  - Merging branches that have a file in one and a directory in
-    another at the same path used to get quite confused.  We
-    handle such a case a bit more carefully, even though that is
-    still left as a conflict for the user to sort out.  This
-    will not be backported to 1.5.1.x series, as it is rather an
-    intrusive change.
-
-  - git-fetch had trouble with a remote with insanely large number
-    of refs.
-
-  - "git clean -d -X" now does not remove non-excluded directories.
-
-  - rebasing (without -m) a series that changes a symlink to a directory
-    in the middle of a path confused git-apply greatly and refused to
-    operate.

Documentation/RelNotes-1.5.3.1.txt

@@ -1,10 +0,0 @@
-GIT v1.5.3.1 Release Notes
-==========================
-
-Fixes since v1.5.3
-------------------
-
-This is solely to fix the generated RPM's dependencies.  We used
-to have git-p4 package but we do not anymore.  As suggested on
-the mailing list, this release makes git-core "Obsolete" git-p4,
-so that yum update would not complain.

Documentation/RelNotes-1.5.3.2.txt

@@ -1,58 +0,0 @@
-GIT v1.5.3.2 Release Notes
-==========================
-
-Fixes since v1.5.3.1
---------------------
-
- * git-push sent thin packs by default, which was not good for
-   the public distribution server (no point in saving transfer
-   while pushing; no point in making the resulting pack less
-   optimum).
-
- * git-svn sometimes terminated with "Malformed network data" when
-   talking over svn:// protocol.
-
- * git-send-email re-issued the same message-id about 10% of the
-   time if you fired off 30 messages within a single second.
-
- * git-stash was not terminating the log message of commits it
-   internally creates with LF.
-
- * git-apply failed to check the size of the patch hunk when its
-   beginning part matched the remainder of the preimage exactly,
-   even though the preimage recorded in the hunk was much larger
-   (therefore the patch should not have applied), leading to a
-   segfault.
-
- * "git rm foo && git commit foo" complained that 'foo' needs to
-   be added first, instead of committing the removal, which was a
-   nonsense.
-
- * git grep -c said "/dev/null: 0".
-
- * git-add -u failed to recognize a blob whose type changed
-   between the index and the work tree.
-
- * The limit to rename detection has been tightened a lot to
-   reduce performance problems with a huge change.
-
- * cvsimport and svnimport barfed when the input tried to move
-   a tag.
-
- * "git apply -pN" did not chop the right number of directories.
-
- * "git svnimport" did not like SVN tags with funny characters in them.
-
- * git-gui 0.8.3, with assorted fixes, including:
-
-   - font-chooser on X11 was unusable with large number of fonts;
-   - a diff that contained a deleted symlink made it barf;
-   - an untracked symbolic link to a directory made it fart;
-   - a file with % in its name made it vomit;
-
-
-Documentation updates
----------------------
-
-User manual has been somewhat restructured.  I think the new
-organization is much easier to read.

Documentation/RelNotes-1.5.3.3.txt

@@ -1,31 +0,0 @@
-GIT v1.5.3.3 Release Notes
-==========================
-
-Fixes since v1.5.3.2
---------------------
-
- * git-quiltimport did not like it when a patch described in the
-   series file does not exist.
-
- * p4 importer missed executable bit in some cases.
-
- * The default shell on some FreeBSD did not execute the
-   argument parsing code correctly and made git unusable.
-
- * git-svn incorrectly spawned pager even when the user
-   explicitly asked not to.
-
- * sample post-receive hook overquoted the envelope sender
-   value.
-
- * git-am got confused when the patch contained a change that is
-   only about type and not contents.
-
- * git-mergetool did not show our and their version of the
-   conflicted file when started from a subdirectory of the
-   project.
-
- * git-mergetool did not pass correct options when invoking diff3.
-
- * git-log sometimes invoked underlying "diff" machinery
-   unnecessarily.

Documentation/RelNotes-1.5.3.4.txt

@@ -1,35 +0,0 @@
-GIT v1.5.3.4 Release Notes
-==========================
-
-Fixes since v1.5.3.3
---------------------
-
- * Change to "git-ls-files" in v1.5.3.3 that was introduced to support
-   partial commit of removal better had a segfaulting bug, which was
-   diagnosed and fixed by Keith and Carl.
-
- * Performance improvements for rename detection has been backported
-   from the 'master' branch.
-
- * "git-for-each-ref --format='%(numparent)'" was not working
-   correctly at all, and --format='%(parent)' was not working for
-   merge commits.
-
- * Sample "post-receive-hook" incorrectly sent out push
-   notification e-mails marked as "From: " the committer of the
-   commit that happened to be at the tip of the branch that was
-   pushed, not from the person who pushed.
-
- * "git-remote" did not exit non-zero status upon error.
-
- * "git-add -i" did not respond very well to EOF from tty nor
-   bogus input.
-
- * "git-rebase -i" squash subcommand incorrectly made the
-   author of later commit the author of resulting commit,
-   instead of taking from the first one in the squashed series.
-
- * "git-stash apply --index" was not documented.
-
- * autoconfiguration learned that "ar" command is found as "gas" on
-   some systems.

Documentation/RelNotes-1.5.3.5.txt

@@ -1,94 +0,0 @@
-GIT v1.5.3.5 Release Notes
-==========================
-
-Fixes since v1.5.3.4
---------------------
-
- * Comes with git-gui 0.8.4.
-
- * "git-config" silently ignored options after --list; now it will
-   error out with a usage message.
-
- * "git-config --file" failed if the argument used a relative path
-   as it changed directories before opening the file.
-
- * "git-config --file" now displays a proper error message if it
-   cannot read the file specified on the command line.
-
- * "git-config", "git-diff", "git-apply" failed if run from a
-   subdirectory with relative GIT_DIR and GIT_WORK_TREE set.
-
- * "git-blame" crashed if run during a merge conflict.
-
- * "git-add -i" did not handle single line hunks correctly.
-
- * "git-rebase -i" and "git-stash apply" failed if external diff
-   drivers were used for one or more files in a commit.  They now
-   avoid calling the external diff drivers.
-
- * "git-log --follow" did not work unless diff generation (e.g. -p)
-   was also requested.
-
- * "git-log --follow -B" did not work at all.  Fixed.
-
- * "git-log -M -B" did not correctly handle cases of very large files
-   being renamed and replaced by very small files in the same commit.
-
- * "git-log" printed extra newlines between commits when a diff
-   was generated internally (e.g. -S or --follow) but not displayed.
-
- * "git-push" error message is more helpful when pushing to a
-   repository with no matching refs and none specified.
-
- * "git-push" now respects + (force push) on wildcard refspecs,
-   matching the behavior of git-fetch.
-
- * "git-filter-branch" now updates the working directory when it
-   has finished filtering the current branch.
-
- * "git-instaweb" no longer fails on Mac OS X.
-
- * "git-cvsexportcommit" didn't always create new parent directories
-   before trying to create new child directories.  Fixed.
-
- * "git-fetch" printed a scary (but bogus) error message while
-   fetching a tag that pointed to a tree or blob.  The error did
-   not impact correctness, only user perception.  The bogus error
-   is no longer printed.
-
- * "git-ls-files --ignored" did not properly descend into non-ignored
-   directories that themselves contained ignored files if d_type
-   was not supported by the filesystem.  This bug impacted systems
-   such as AFS.  Fixed.
-
- * Git segfaulted when reading an invalid .gitattributes file.  Fixed.
-
- * post-receive-email example hook was fixed for non-fast-forward
-   updates.
-
- * Documentation updates for supported (but previously undocumented)
-   options of "git-archive" and "git-reflog".
-
- * "make clean" no longer deletes the configure script that ships
-   with the git tarball, making multiple architecture builds easier.
-
- * "git-remote show origin" spewed a warning message from Perl
-   when no remote is defined for the current branch via
-   branch.<name>.remote configuration settings.
-
- * Building with NO_PERL_MAKEMAKER excessively rebuilt contents
-   of perl/ subdirectory by rewriting perl.mak.
-
- * http.sslVerify configuration settings were not used in scripted
-   Porcelains.
-
- * "git-add" leaked a bit of memory while scanning for files to add.
-
- * A few workarounds to squelch false warnings from recent gcc have
-   been added.
-
- * "git-send-pack $remote frotz" segfaulted when there is nothing
-   named 'frotz' on the local end.
-
- * "git-rebase --interactive" did not handle its "--strategy" option
-   properly.

Documentation/RelNotes-1.5.3.6.txt

@@ -1,48 +0,0 @@
-GIT v1.5.3.6 Release Notes
-==========================
-
-Fixes since v1.5.3.5
---------------------
-
- * git-cvsexportcommit handles root commits better.
-
- * git-svn dcommit used to clobber when sending a series of
-   patches.
-
- * git-svn dcommit failed after attempting to rebase when
-   started with a dirty index; now it stops upfront.
-
- * git-grep sometimes refused to work when your index was
-   unmerged.
-
- * "git-grep -A1 -B2" acted as if it was told to run "git -A1 -B21".
-
- * git-hash-object did not honor configuration variables, such as
-   core.compression.
-
- * git-index-pack choked on a huge pack on 32-bit machines, even when
-   large file offsets are supported.
-
- * atom feeds from git-web said "10" for the month of November.
-
- * a memory leak in commit walker was plugged.
-
- * When git-send-email inserted the original author's From:
-   address in body, it did not mark the message with
-   Content-type: as needed.
-
- * git-revert and git-cherry-pick incorrectly refused to start
-   when the work tree was dirty.
-
- * git-clean did not honor core.excludesfile configuration.
-
- * git-add mishandled ".gitignore" files when applying them to
-   subdirectories.
-
- * While importing a too branchy history, git-fastimport did not
-   honor delta depth limit properly.
-
- * Support for zlib implementations that lack ZLIB_VERNUM and definition
-   of deflateBound() has been added.
-
- * Quite a lot of documentation clarifications.

Documentation/RelNotes-1.5.3.7.txt

@@ -1,45 +0,0 @@
-GIT v1.5.3.7 Release Notes
-==========================
-
-Fixes since v1.5.3.6
---------------------
-
- * git-send-email added 8-bit contents to the payload without
-   marking it as 8-bit in a CTE header.
-
- * "git-bundle create a.bndl HEAD" dereferenced the symref and
-   did not record the ref as 'HEAD'; this prevented a bundle
-   from being used as a normal source of git-clone.
-
- * The code to reject nonsense command line of the form
-   "git-commit -a paths..." and "git-commit --interactive
-   paths..." were broken.
-
- * Adding a signature that is not ASCII-only to an original
-   commit that is ASCII-only would make the result non-ASCII.
-   "git-format-patch -s" did not mark such a message correctly
-   with MIME encoding header.
-
- * git-add sometimes did not mark the resulting index entry
-   stat-clean.  This affected only cases when adding the
-   contents with the same length as the previously staged
-   contents, and the previous staging made the index entry
-   "racily clean".
-
- * git-commit did not honor GIT_INDEX_FILE the user had in the
-   environment.
-
- * When checking out a revision, git-checkout did not report where the
-   updated HEAD is if you happened to have a file called HEAD in the
-   work tree.
-
- * "git-rev-list --objects" mishandled a tree that points at a
-   submodule.
-
- * "git cvsimport" was not ready for packed refs that "git gc" can
-   produce and gave incorrect results.
-
- * Many scripted Porcelains were confused when you happened to have a
-   file called "HEAD" in your work tree.
-
-Also it contains updates to the user manual and documentation.

Documentation/RelNotes-1.5.3.8.txt

@@ -1,25 +0,0 @@
-GIT v1.5.3.8 Release Notes
-==========================
-
-Fixes since v1.5.3.7
---------------------
-
- * Some documentation used "email.com" as an example domain.
-
- * git-svn fix to handle funky branch and project names going over
-   http/https correctly.
-
- * git-svn fix to tone down a needlessly alarming warning message.
-
- * git-clone did not correctly report errors while fetching over http.
-
- * git-send-email added redundant Message-Id: header to the outgoing
-   e-mail when the patch text already had one.
-
- * a read-beyond-end-of-buffer bug in configuration file updater was fixed.
-
- * git-grep used to show the same hit repeatedly for unmerged paths.
-
- * After amending the patch title in "git-am -i", the command did not
-   report the patch it applied with the updated title.
-

Documentation/RelNotes-1.5.3.txt

@@ -1,366 +0,0 @@
-GIT v1.5.3 Release Notes
-========================
-
-Updates since v1.5.2
---------------------
-
-* The commit walkers other than http are officially deprecated,
-  but still supported for now.
-
-* The submodule support has Porcelain layer.
-
-  Note that the current submodule support is minimal and this is
-  deliberately so.  A design decision we made is that operations
-  at the supermodule level do not recurse into submodules by
-  default.  The expectation is that later we would add a
-  mechanism to tell git which submodules the user is interested
-  in, and this information might be used to determine the
-  recursive behaviour of certain commands (e.g. "git checkout"
-  and "git diff"), but currently we haven't agreed on what that
-  mechanism should look like.  Therefore, if you use submodules,
-  you would probably need "git submodule update" on the
-  submodules you care about after running a "git checkout" at
-  the supermodule level.
-
-* There are a handful pack-objects changes to help you cope better
-  with repositories with pathologically large blobs in them.
-
-* For people who need to import from Perforce, a front-end for
-  fast-import is in contrib/fast-import/.
-
-* Comes with git-gui 0.8.2.
-
-* Comes with updated gitk.
-
-* New commands and options.
-
-  - "git log --date=<format>" can use more formats: iso8601, rfc2822.
-
-  - The hunk header output from "git diff" family can be customized
-    with the attributes mechanism.  See gitattributes(5) for details.
-
-  - "git stash" allows you to quickly save away your work in
-    progress and replay it later on an updated state.
-
-  - "git rebase" learned an "interactive" mode that let you
-    pick and reorder which commits to rebuild.
-
-  - "git fsck" can save its findings in $GIT_DIR/lost-found, without a
-    separate invocation of "git lost-found" command.  The blobs stored by
-    lost-found are stored in plain format to allow you to grep in them.
-
-  - $GIT_WORK_TREE environment variable can be used together with
-    $GIT_DIR to work in a subdirectory of a working tree that is
-    not located at "$GIT_DIR/..".
-
-  - Giving "--file=<file>" option to "git config" is the same as
-    running the command with GIT_CONFIG=<file> environment.
-
-  - "git log" learned a new option "--follow", to follow
-    renaming history of a single file.
-
-  - "git filter-branch" lets you rewrite the revision history of
-    specified branches. You can specify a number of filters to
-    modify the commits, files and trees.
-
-  - "git cvsserver" learned new options (--base-path, --export-all,
-    --strict-paths) inspired by "git daemon".
-
-  - "git daemon --base-path-relaxed" can help migrating a repository URL
-    that did not use to use --base-path to use --base-path.
-
-  - "git commit" can use "-t templatefile" option and commit.template
-    configuration variable to prime the commit message given to you in the
-    editor.
-
-  - "git submodule" command helps you manage the projects from
-    the superproject that contain them.
-
-  - In addition to core.compression configuration option,
-    core.loosecompression and pack.compression options can
-    independently tweak zlib compression levels used for loose
-    and packed objects.
-
-  - "git ls-tree -l" shows size of blobs pointed at by the
-    tree entries, similar to "/bin/ls -l".
-
-  - "git rev-list" learned --regexp-ignore-case and
-    --extended-regexp options to tweak its matching logic used
-    for --grep fitering.
-
-  - "git describe --contains" is a handier way to call more
-    obscure command "git name-rev --tags".
-
-  - "git gc --aggressive" tells the command to spend more cycles
-    to optimize the repository harder.
-
-  - "git repack" learned a "window-memory" limit which
-    dynamically reduces the window size to stay within the
-    specified memory usage.
-
-  - "git repack" can be told to split resulting packs to avoid
-    exceeding limit specified with "--max-pack-size".
-
-  - "git fsck" gained --verbose option.  This is really really
-    verbose but it might help you identify exact commit that is
-    corrupt in your repository.
-
-  - "git format-patch" learned --numbered-files option.  This
-    may be useful for MH users.
-
-  - "git format-patch" learned format.subjectprefix configuration
-    variable, which serves the same purpose as "--subject-prefix"
-    option.
-
-  - "git tag -n -l" shows tag annotations while listing tags.
-
-  - "git cvsimport" can optionally use the separate-remote layout.
-
-  - "git blame" can be told to see through commits that change
-    whitespaces and indentation levels with "-w" option.
-
-  - "git send-email" can be told not to thread the messages when
-    sending out more than one patches.
-
-  - "git send-email" can also be told how to find whom to cc the
-    message to for each message via --cc-cmd.
-
-  - "git config" learned NUL terminated output format via -z to
-    help scripts.
-
-  - "git add" learned "--refresh <paths>..." option to selectively refresh
-    the cached stat information.
-
-  - "git init -q" makes the command quieter.
-
-  - "git -p command" now has a cousin of opposite sex, "git --no-pager
-    command".
-
-* Updated behavior of existing commands.
-
-  - "gitweb" can offer multiple snapshot formats.
-
-    ***NOTE*** Unfortunately, this changes the format of the
-    $feature{snapshot}{default} entry in the per-site
-    configuration file 'gitweb_config.perl'.  It used to be a
-    three-element tuple that describe a single format; with the
-    new configuration item format, you only have to say the name
-    of the format ('tgz', 'tbz2' or 'zip').  Please update the
-    your configuration file accordingly.
-
-  - "git clone" uses -l (hardlink files under .git) by default when
-    cloning locally.
-
-  - URL used for "git clone" and friends can specify nonstandard SSH port
-    by using ssh://host:port/path/to/repo syntax.
-
-  - "git bundle create" can now create a bundle without negative refs,
-    i.e. "everything since the beginning up to certain points".
-
-  - "git diff" (but not the plumbing level "git diff-tree") now
-    recursively descends into trees by default.
-
-  - "git diff" does not show differences that come only from
-    stat-dirtiness in the form of "diff --git" header anymore.
-    It runs "update-index --refresh" silently as needed.
-
-  - "git tag -l" used to match tags by globbing its parameter as if it
-    has wildcard '*' on both ends, which made "git tag -l gui" to match
-    tag 'gitgui-0.7.0'; this was very annoying.  You now have to add
-    asterisk on the sides you want to wildcard yourself.
-
-  - The editor to use with many interactive commands can be
-    overridden with GIT_EDITOR environment variable, or if it
-    does not exist, with core.editor configuration variable.  As
-    before, if you have neither, environment variables VISUAL
-    and EDITOR are consulted in this order, and then finally we
-    fall back on "vi".
-
-  - "git rm --cached" does not complain when removing a newly
-    added file from the index anymore.
-
-  - Options to "git log" to affect how --grep/--author options look for
-    given strings now have shorter abbreviations.  -i is for ignore case,
-    and -E is for extended regexp.
-
-  - "git log" learned --log-size to show the number of bytes in
-    the log message part of the output to help qgit.
-
-  - "git log --name-status" does not require you to give "-r" anymore.
-    As a general rule, Porcelain commands should recurse when showing
-    diff.
-
-  - "git format-patch --root A" can be used to format everything
-    since the beginning up to A.  This was supported with
-    "git format-patch --root A A" for a long time, but was not
-    properly documented.
-
-  - "git svn dcommit" retains local merge information.
-
-  - "git svnimport" allows an empty string to be specified as the
-    trunk/ directory.  This is necessary to suck data from a SVN
-    repository that doe not have trunk/ branches/ and tags/ organization
-    at all.
-
-  - "git config" to set values also honors type flags like --bool
-    and --int.
-
-  - core.quotepath configuration can be used to make textual git
-    output to emit most of the characters in the path literally.
-
-  - "git mergetool" chooses its backend more wisely, taking
-    notice of its environment such as use of X, Gnome/KDE, etc.
-
-  - "gitweb" shows merge commits a lot nicer than before.  The
-    default view uses more compact --cc format, while the UI
-    allows to choose normal diff with any parent.
-
-  - snapshot files "gitweb" creates from a repository at
-    $path/$project/.git are more useful.  We use $project part
-    in the filename, which we used to discard.
-
-  - "git cvsimport" creates lightweight tags; there is no
-    interesting information we can record in an annotated tag,
-    and the handcrafted ones the old code created was not
-    properly formed anyway.
-
-  - "git push" pretends that you immediately fetched back from
-    the remote by updating corresponding remote tracking
-    branches if you have any.
-
-  - The diffstat given after a merge (or a pull) honors the
-    color.diff configuration.
-
-  - "git commit --amend" is now compatible with various message source
-    options such as -m/-C/-c/-F.
-
-  - "git apply --whitespace=strip" removes blank lines added at
-    the end of the file.
-
-  - "git fetch" over git native protocols with "-v" option shows
-    connection status, and the IP address of the other end, to
-    help diagnosing problems.
-
-  - We used to have core.legacyheaders configuration, when
-    set to false, allowed git to write loose objects in a format
-    that mimicks the format used by objects stored in packs.  It
-    turns out that this was not so useful.  Although we will
-    continue to read objects written in that format, we do not
-    honor that configuration anymore and create loose objects in
-    the legacy/traditional format.
-
-  - "--find-copies-harder" option to diff family can now be
-    spelled as "-C -C" for brevity.
-
-  - "git mailsplit" (hence "git am") can read from Maildir
-    formatted mailboxes.
-
-  - "git cvsserver" does not barf upon seeing "cvs login"
-    request.
-
-  - "pack-objects" honors "delta" attribute set in
-    .gitattributes.  It does not attempt to deltify blobs that
-    come from paths with delta attribute set to false.
-
-  - "new-workdir" script (in contrib) can now be used with a
-    bare repository.
-
-  - "git mergetool" learned to use gvimdiff.
-
-  - "gitview" (in contrib) has a better blame interface.
-
-  - "git log" and friends did not handle a commit log message
-    that is larger than 16kB; they do now.
-
-  - "--pretty=oneline" output format for "git log" and friends
-    deals with "malformed" commit log messages that have more
-    than one lines in the first paragraph better.  We used to
-    show the first line, cutting the title at mid-sentence; we
-    concatenate them into a single line and treat the result as
-    "oneline".
-
-  - "git p4import" has been demoted to contrib status.  For
-    a superior option, checkout the "git p4" front end to
-    "git fast-import" (also in contrib).  The man page and p4
-    rpm have been removed as well.
-
-  - "git mailinfo" (hence "am") now tries to see if the message
-    is in utf-8 first, instead of assuming iso-8859-1, if
-    incoming e-mail does not say what encoding it is in.
-
-* Builds
-
-  - old-style function definitions (most notably, a function
-    without parameter defined with "func()", not "func(void)")
-    have been eradicated.
-
-  - "git tag" and "git verify-tag" have been rewritten in C.
-
-* Performance Tweaks
-
-  - "git pack-objects" avoids re-deltification cost by caching
-    small enough delta results it creates while looking for the
-    best delta candidates.
-
-  - "git pack-objects" learned a new heuristcs to prefer delta
-    that is shallower in depth over the smallest delta
-    possible.  This improves both overall packfile access
-    performance and packfile density.
-
-  - diff-delta code that is used for packing has been improved
-    to work better on big files.
-
-  - when there are more than one pack files in the repository,
-    the runtime used to try finding an object always from the
-    newest packfile; it now tries the same packfile as we found
-    the object requested the last time, which exploits the
-    locality of references.
-
-  - verifying pack contents done by "git fsck --full" got boost
-    by carefully choosing the order to verify objects in them.
-
-  - "git read-tree -m" to read into an already populated index
-    has been optimized vastly.  The effect of this can be seen
-    when switching branches that have differences in only a
-    handful paths.
-
-  - "git add paths..." and "git commit paths..." has also been
-    heavily optimized.
-
-Fixes since v1.5.2
-------------------
-
-All of the fixes in v1.5.2 maintenance series are included in
-this release, unless otherwise noted.
-
-* Bugfixes
-
-  - "gitweb" had trouble handling non UTF-8 text with older
-    Encode.pm Perl module.
-
-  - "git svn" misparsed the data from the commits in the repository when
-    the user had "color.diff = true" in the configuration.  This has been
-    fixed.
-
-  - There was a case where "git svn dcommit" clobbered changes made on the
-    SVN side while committing multiple changes.
-
-  - "git-write-tree" had a bad interaction with racy-git avoidance and
-    gitattributes mechanisms.
-
-  - "git --bare command" overrode existing GIT_DIR setting and always
-    made it treat the current working directory as GIT_DIR.
-
-  - "git ls-files --error-unmatch" does not complain if you give the
-    same path pattern twice by mistake.
-
-  - "git init" autodetected core.filemode but not core.symlinks, which
-    made a new directory created automatically by "git clone" cumbersome
-    to use on filesystems that require these configurations to be set.
-
-  - "git log" family of commands behaved differently when run as "git
-    log" (no pathspec) and as "git log --" (again, no pathspec).  This
-    inconsistency was introduced somewhere in v1.3.0 series but now has
-    been corrected.
-
-  - "git rebase -m" incorrectly displayed commits that were skipped.

Documentation/RelNotes-1.5.4.1.txt

@@ -1,17 +0,0 @@
-GIT v1.5.4.1 Release Notes
-==========================
-
-Fixes since v1.5.4
-------------------
-
- * "git-commit -C $tag" used to work but rewrite in C done in
-   1.5.4 broke it.
-
- * An entry in the .gitattributes file that names a pattern in a
-   subdirectory of the directory it is in did not match
-   correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should
-   match "a/b/foo.c" but it didn't).
-
- * Customized color specification was parsed incorrectly when
-   numeric color values are used.  This was fixed in 1.5.4.1.
-

Documentation/RelNotes-1.5.4.2.txt

@@ -1,43 +0,0 @@
-GIT v1.5.4.2 Release Notes
-==========================
-
-Fixes since v1.5.4
-------------------
-
- * The configuration parser was not prepared to see string
-   valued variables misspelled as boolean and segfaulted.
-
- * Temporary files left behind due to interrupted object
-   transfers were not cleaned up with "git prune".
-
- * "git config --unset" was confused when the unset variables
-   were spelled with continuation lines in the config file.
-
- * The merge message detection in "git cvsimport" did not catch
-   a message that began with "Merge...".
-
- * "git status" suggests "git rm --cached" for unstaging the
-   earlier "git add" before the initial commit.
-
- * "git status" output was incorrect during a partial commit.
-
- * "git bisect" refused to start when the HEAD was detached.
-
- * "git bisect" allowed a wildcard character in the commit
-   message expanded while writing its log file.
-
- * Manual pages were not formatted correctly with docbook xsl
-   1.72; added a workaround.
-
- * "git-commit -C $tag" used to work but rewrite in C done in
-   1.5.4 broke it.  This was fixed in 1.5.4.1.
-
- * An entry in the .gitattributes file that names a pattern in a
-   subdirectory of the directory it is in did not match
-   correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should
-   match "a/b/foo.c" but it didn't).  This was fixed in 1.5.4.1.
-
- * Customized color specification was parsed incorrectly when
-   numeric color values are used.  This was fixed in 1.5.4.1.
-
- * http transport misbehaved when linked with curl-gnutls.

Documentation/RelNotes-1.5.4.txt

@@ -1,377 +0,0 @@
-GIT v1.5.4 Release Notes
-========================
-
-Removal
--------
-
- * "git svnimport" was removed in favor of "git svn".  It is still there
-   in the source tree (contrib/examples) but unsupported.
-
- * As git-commit and git-status have been rewritten, "git runstatus"
-   helper script lost all its users and has been removed.
-
-
-Temporarily disabled
---------------------
-
- * "git http-push" is known not to work well with cURL library older
-   than 7.16, and we had reports of repository corruption.  It is
-   disabled on such platforms for now.  Unfortunately, 1.5.3.8 shares
-   the same issue.  In other words, this does not mean you will be
-   fine if you stick to an older git release.  For now, please do not
-   use http-push from older git with cURL older than 7.16 if you
-   value your data. A proper fix will hopefully materialize in
-   later versions.
-
-
-Deprecation notices
--------------------
-
- * From v1.6.0, git will by default install dashed form of commands
-   (e.g. "git-commit") outside of users' normal $PATH, and will install
-   only selected commands ("git" itself, and "gitk") in $PATH.  This
-   implies:
-
-   - Using dashed forms of git commands (e.g. "git-commit") from the
-     command line has been informally deprecated since early 2006, but
-     now it officially is, and will be removed in the future.  Use
-     dash-less forms (e.g. "git commit") instead.
-
-   - Using dashed forms from your scripts, without first prepending the
-     return value from "git --exec-path" to the scripts' PATH, has been
-     informally deprecated since early 2006, but now it officially is.
-
-   - Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
-     PATH" early in your script is not deprecated with this change.
-
-   Users are strongly encouraged to adjust their habits and scripts now
-   to prepare for this change.
-
- * The post-receive hook was introduced in March 2007 to supersede
-   the post-update hook, primarily to overcome the command line length
-   limitation of the latter.  Use of post-update hook will be deprecated
-   in future versions of git, starting from v1.6.0.
-
- * "git lost-found" was deprecated in favor of "git fsck"'s --lost-found
-   option, and will be removed in the future.
-
- * "git peek-remote" is deprecated, as "git ls-remote" was written in C
-   and works for all transports; "git peek-remote" will be removed in
-   the future.
-
- * "git repo-config" which was an old name for "git config" command
-   has been supported without being advertised for a long time.  The
-   next feature release will remove it.
-
- * From v1.6.0, the repack.usedeltabaseoffset config option will default
-   to true, which will give denser packfiles (i.e. more efficient storage).
-   The downside is that git older than version 1.4.4 will not be able
-   to directly use a repository packed using this setting.
-
- * From v1.6.0, the pack.indexversion config option will default to 2,
-   which is slightly more efficient, and makes repacking more immune to
-   data corruptions.  Git older than version 1.5.2 may revert to version 1
-   of the pack index with a manual "git index-pack" to be able to directly
-   access corresponding pack files.
-
-
-Updates since v1.5.3
---------------------
-
- * Comes with much improved gitk, with i18n.
-
- * Comes with git-gui 0.9.2 with i18n.
-
- * gitk is now merged as a subdirectory of git.git project, in
-   preparation for its i18n.
-
- * progress displays from many commands are a lot nicer to the eye.
-   Transfer commands show throughput data.
-
- * many commands that pay attention to per-directory .gitignore now do
-   so lazily, which makes the usual case go much faster.
-
- * Output processing for '--pretty=format:<user format>' has been
-   optimized.
-
- * Rename detection of diff family while detecting exact matches has
-   been greatly optimized.
-
- * Rename detection of diff family tries to make more natural looking
-   pairing.  Earlier, if multiple identical rename sources were
-   found in the preimage, the source used was picked pretty much at random.
-
- * Value "true" for color.diff and color.status configuration used to
-   mean "always" (even when the output is not going to a terminal).
-   This has been corrected to mean the same thing as "auto".
-
- * "git diff" Porcelain now respects diff.external configuration, which
-   is another way to specify GIT_EXTERNAL_DIFF.
-
- * "git diff" can be told to use different prefixes other than
-   "a/" and "b/" e.g. "git diff --src-prefix=l/ --dst-prefix=k/".
-
- * "git diff" sometimes did not quote paths with funny
-   characters properly.
-
- * "git log" (and any revision traversal commands) misbehaved
-   when --diff-filter is given but was not asked to actually
-   produce diff.
-
- * HTTP proxy can be specified per remote repository using
-   remote.*.httpproxy configuration, or global http.proxy configuration
-   variable.
-
- * Various Perforce importer updates.
-
- * Example update and post-receive hooks have been improved.
-
- * Any command that wants to take a commit object name can now use
-   ":/string" syntax to name a commit.
-
- * "git reset" is now built-in and its output can be squelched with -q.
-
- * "git reset --hard" does not make any sense in a bare
-   repository, but did not error out; fixed.
-
- * "git send-email" can optionally talk over ssmtp and use SMTP-AUTH.
-
- * "git rebase" learned --whitespace option.
-
- * In "git rebase", when you decide not to replay a particular change
-   after the command stopped with a conflict, you can say "git rebase
-   --skip" without first running "git reset --hard", as the command now
-   runs it for you.
-
- * "git rebase --interactive" mode can now work on detached HEAD.
-
- * Other minor to serious bugs in "git rebase -i" have been fixed.
-
- * "git rebase" now detaches head during its operation, so after a
-   successful "git rebase" operation, the reflog entry branch@{1} for
-   the current branch points at the commit before the rebase was
-   started.
-
- * "git rebase -i" also triggers rerere to help your repeated merges.
-
- * "git merge" can call the "post-merge" hook.
-
- * "git pack-objects" can optionally run deltification with multiple
-   threads.
-
- * "git archive" can optionally substitute keywords in files marked with
-   export-subst attribute.
-
- * "git cherry-pick" made a misguided attempt to repeat the original
-   command line in the generated log message, when told to cherry-pick a
-   commit by naming a tag that points at it.  It does not anymore.
-
- * "git for-each-ref" learned %(xxxdate:<date-format>) syntax to show the
-   various date fields in different formats.
-
- * "git gc --auto" is a low-impact way to automatically run a variant of
-   "git repack" that does not lose unreferenced objects (read: safer
-   than the usual one) after the user accumulates too many loose
-   objects.
-
- * "git clean" has been rewritten in C.
-
- * You need to explicitly set clean.requireForce to "false" to allow
-   "git clean" without -f to do any damage (lack of the configuration
-   variable used to mean "do not require -f option to lose untracked
-   files", but we now use the safer default).
-
- * The kinds of whitespace errors "git diff" and "git apply" notice (and
-   fix) can be controlled via 'core.whitespace' configuration variable
-   and 'whitespace' attribute in .gitattributes file.
-
- * "git push" learned --dry-run option to show what would happen if a
-   push is run.
-
- * "git push" does not update a tracking ref on the local side when the
-   remote refused to update the corresponding ref.
-
- * "git push" learned --mirror option.  This is to push the local refs
-   one-to-one to the remote, and deletes refs from the remote that do
-   not exist anymore in the repository on the pushing side.
-
- * "git push" can remove a corrupt ref at the remote site with the usual
-   ":ref" refspec.
-
- * "git remote" knows --mirror mode.  This is to set up configuration to
-   push into a remote repository to store local branch heads to the same
-   branch on the remote side, and remove branch heads locally removed
-   from local repository at the same time.  Suitable for pushing into a
-   back-up repository.
-
- * "git remote" learned "rm" subcommand.
-
- * "git cvsserver" can be run via "git shell".  Also, "cvs" is
-   recognized as a synonym for "git cvsserver", so that CVS users
-   can be switched to git just by changing their login shell.
-
- * "git cvsserver" acts more like receive-pack by running post-receive
-   and post-update hooks.
-
- * "git am" and "git rebase" are far less verbose.
-
- * "git pull" learned to pass --[no-]ff option to underlying "git
-   merge".
-
- * "git pull --rebase" is a different way to integrate what you fetched
-   into your current branch.
-
- * "git fast-export" produces data-stream that can be fed to fast-import
-   to reproduce the history recorded in a git repository.
-
- * "git add -i" takes pathspecs to limit the set of files to work on.
-
- * "git add -p" is a short-hand to go directly to the selective patch
-   subcommand in the interactive command loop and to exit when done.
-
- * "git add -i" UI has been colorized.  The interactive prompt
-   and menu can be colored by setting color.interactive
-   configuration.  The diff output (including the hunk picker)
-   are colored with color.diff configuration.
-
- * "git commit --allow-empty" allows you to create a single-parent
-   commit that records the same tree as its parent, overriding the usual
-   safety valve.
-
- * "git commit --amend" can amend a merge that does not change the tree
-   from its first parent.
-
- * "git commit" used to unconditionally strip comment lines that
-   began with '#' and removed excess blank lines.  This behavior has
-   been made configurable.
-
- * "git commit" has been rewritten in C.
-
- * "git stash random-text" does not create a new stash anymore.  It was
-   a UI mistake.  Use "git stash save random-text", or "git stash"
-   (without extra args) for that.
-
- * "git stash clear extra-text" does not clear the whole stash
-   anymore.  It is tempting to expect "git stash clear stash@{2}"
-   to drop only a single named stash entry, and it is rude to
-   discard everything when that is asked (but not provided).
-
- * "git prune --expire <time>" can exempt young loose objects from
-   getting pruned.
-
- * "git branch --contains <commit>" can list branches that are
-   descendants of a given commit.
-
- * "git log" learned --early-output option to help interactive GUI
-   implementations.
-
- * "git bisect" learned "skip" action to mark untestable commits.
-
- * "git bisect visualize" learned a shorter synonym "git bisect view".
-
- * "git bisect visualize" runs "git log" in a non-windowed
-   environments.  It also can be told what command to run (e.g. "git
-   bisect visualize tig").
-
- * "git format-patch" learned "format.numbered" configuration variable
-   to automatically turn --numbered option on when more than one commits
-   are formatted.
-
- * "git ls-files" learned "--exclude-standard" to use the canned set of
-   exclude files.
-
- * "git tag -a -f existing" begins the editor session using the existing
-   annotation message.
-
- * "git tag -m one -m bar" (multiple -m options) behaves similarly to
-   "git commit"; the parameters to -m options are formatted as separate
-   paragraphs.
-
- * The format "git show" outputs an annotated tag has been updated to
-   include "Tagger: " and "Date: " lines from the tag itself.  Strictly
-   speaking this is a backward incompatible change, but this is a
-   reasonable usability fix and people's scripts shouldn't have been
-   relying on the exact output from "git show" Porcelain anyway.
-
- * "git cvsimport" did not notice errors from underlying "cvsps"
-   and produced a corrupt import silently.
-
- * "git cvsexportcommit" learned -w option to specify and switch to the
-   CVS working directory.
-
- * "git checkout" from a subdirectory learned to use "../path" to allow
-   checking out a path outside the current directory without cd'ing up.
-
- * "git checkout" from and to detached HEAD leaves a bit more
-   information in the reflog.
-
- * "git send-email --dry-run" shows full headers for easier diagnosis.
-
- * "git merge-ours" is now built-in.
-
- * "git svn" learned "info" and "show-externals" subcommands.
-
- * "git svn" run from a subdirectory failed to read settings from the
-   .git/config.
-
- * "git svn" learned --use-log-author option, which picks up more
-   descriptive name from From: and Signed-off-by: lines in the commit
-   message.
-
- * "git svn" wasted way too much disk to record revision mappings
-   between svn and git; a new representation that is much more compact
-   for this information has been introduced to correct this.
-
- * "git svn" left temporary index files it used without cleaning them
-   up; this was corrected.
-
- * "git status" from a subdirectory now shows relative paths, which
-   makes copy-and-pasting for git-checkout/git-add/git-rm easier.  The
-   traditional behavior to show the full path relative to the top of
-   the work tree can be had by setting status.relativepaths
-   configuration variable to false.
-
- * "git blame" kept text for each annotated revision in core needlessly;
-   this has been corrected.
-
- * "git shortlog" learned to default to HEAD when the standard input is
-   a terminal and the user did not give any revision parameter.
-
- * "git shortlog" learned "-e" option to show e-mail addresses as well as
-   authors' names.
-
- * "git help" learned "-w" option to show documentation in browsers.
-
- * In addition there are quite a few internal clean-ups. Notably:
-
-   - many fork/exec have been replaced with run-command API,
-     brought from the msysgit effort.
-
-   - introduction and more use of the option parser API.
-
-   - enhancement and more use of the strbuf API.
-
- * Makefile tweaks to support HP-UX is in.
-
-Fixes since v1.5.3
-------------------
-
-All of the fixes in v1.5.3 maintenance series are included in
-this release, unless otherwise noted.
-
-These fixes are only in v1.5.4 and not backported to v1.5.3 maintenance
-series.
-
- * The way "git diff --check" behaves is much more consistent with the way
-   "git apply --whitespace=warn" works.
-
- * "git svn" talking with the SVN over HTTP will correctly quote branch
-   and project names.
-
- * "git config" did not work correctly on platforms that define
-   REG_NOMATCH to an even number.
-
- * Recent versions of AsciiDoc 8 has a change to break our
-   documentation; a workaround has been implemented.
-
- * "git diff --color-words" colored context lines in a wrong color.

Documentation/SubmittingPatches

@@ -1,404 +0,0 @@
-Checklist (and a short version for the impatient):
-
-	Commits:
-
-	- make commits of logical units
-	- check for unnecessary whitespace with "git diff --check"
-	  before committing
-	- do not check in commented out code or unneeded files
-	- provide a meaningful commit message
-	- the first line of the commit message should be a short
-	  description and should skip the full stop
-	- if you want your work included in git.git, add a
-	  "Signed-off-by: Your Name <you@example.com>" line to the
-	  commit message (or just use the option "-s" when
-	  committing) to confirm that you agree to the Developer's
-	  Certificate of Origin
-	- make sure that you have tests for the bug you are fixing
-	- make sure that the test suite passes after your commit
-
-	Patch:
-
-	- use "git format-patch -M" to create the patch
-	- do not PGP sign your patch
-	- do not attach your patch, but read in the mail
-	  body, unless you cannot teach your mailer to
-	  leave the formatting of the patch alone.
-	- be careful doing cut & paste into your mailer, not to
-	  corrupt whitespaces.
-	- provide additional information (which is unsuitable for
-	  the commit message) between the "---" and the diffstat
-	- if you change, add, or remove a command line option or
-	  make some other user interface change, the associated
-	  documentation should be updated as well.
-	- if your name is not writable in ASCII, make sure that
-	  you send off a message in the correct encoding.
-	- send the patch to the list (git@vger.kernel.org) and the
-	  maintainer (gitster@pobox.com). If you use
-	  git-send-email(1), please test it first by sending
-	  email to yourself.
-
-Long version:
-
-I started reading over the SubmittingPatches document for Linux
-kernel, primarily because I wanted to have a document similar to
-it for the core GIT to make sure people understand what they are
-doing when they write "Signed-off-by" line.
-
-But the patch submission requirements are a lot more relaxed
-here on the technical/contents front, because the core GIT is
-thousand times smaller ;-).  So here is only the relevant bits.
-
-
-(1) Make separate commits for logically separate changes.
-
-Unless your patch is really trivial, you should not be sending
-out a patch that was generated between your working tree and
-your commit head.  Instead, always make a commit with complete
-commit message and generate a series of patches from your
-repository.  It is a good discipline.
-
-Describe the technical detail of the change(s).
-
-If your description starts to get too long, that's a sign that you
-probably need to split up your commit to finer grained pieces.
-
-Oh, another thing.  I am picky about whitespaces.  Make sure your
-changes do not trigger errors with the sample pre-commit hook shipped
-in templates/hooks--pre-commit.  To help ensure this does not happen,
-run git diff --check on your changes before you commit.
-
-
-(1a) Try to be nice to older C compilers
-
-We try to support wide range of C compilers to compile
-git with. That means that you should not use C99 initializers, even
-if a lot of compilers grok it.
-
-Also, variables have to be declared at the beginning of the block
-(you can check this with gcc, using the -Wdeclaration-after-statement
-option).
-
-Another thing: NULL pointers shall be written as NULL, not as 0.
-
-
-(2) Generate your patch using git tools out of your commits.
-
-git based diff tools (git, Cogito, and StGIT included) generate
-unidiff which is the preferred format.
-
-You do not have to be afraid to use -M option to "git diff" or
-"git format-patch", if your patch involves file renames.  The
-receiving end can handle them just fine.
-
-Please make sure your patch does not include any extra files
-which do not belong in a patch submission.  Make sure to review
-your patch after generating it, to ensure accuracy.  Before
-sending out, please make sure it cleanly applies to the "master"
-branch head.  If you are preparing a work based on "next" branch,
-that is fine, but please mark it as such.
-
-
-(3) Sending your patches.
-
-People on the git mailing list need to be able to read and
-comment on the changes you are submitting.  It is important for
-a developer to be able to "quote" your changes, using standard
-e-mail tools, so that they may comment on specific portions of
-your code.  For this reason, all patches should be submitted
-"inline".  WARNING: Be wary of your MUAs word-wrap
-corrupting your patch.  Do not cut-n-paste your patch; you can
-lose tabs that way if you are not careful.
-
-It is a common convention to prefix your subject line with
-[PATCH].  This lets people easily distinguish patches from other
-e-mail discussions.
-
-"git format-patch" command follows the best current practice to
-format the body of an e-mail message.  At the beginning of the
-patch should come your commit message, ending with the
-Signed-off-by: lines, and a line that consists of three dashes,
-followed by the diffstat information and the patch itself.  If
-you are forwarding a patch from somebody else, optionally, at
-the beginning of the e-mail message just before the commit
-message starts, you can put a "From: " line to name that person.
-
-You often want to add additional explanation about the patch,
-other than the commit message itself.  Place such "cover letter"
-material between the three dash lines and the diffstat.
-
-Do not attach the patch as a MIME attachment, compressed or not.
-Do not let your e-mail client send quoted-printable.  Do not let
-your e-mail client send format=flowed which would destroy
-whitespaces in your patches. Many
-popular e-mail applications will not always transmit a MIME
-attachment as plain text, making it impossible to comment on
-your code.  A MIME attachment also takes a bit more time to
-process.  This does not decrease the likelihood of your
-MIME-attached change being accepted, but it makes it more likely
-that it will be postponed.
-
-Exception:  If your mailer is mangling patches then someone may ask
-you to re-send them using MIME, that is OK.
-
-Do not PGP sign your patch, at least for now.  Most likely, your
-maintainer or other people on the list would not have your PGP
-key and would not bother obtaining it anyway.  Your patch is not
-judged by who you are; a good patch from an unknown origin has a
-far better chance of being accepted than a patch from a known,
-respected origin that is done poorly or does incorrect things.
-
-If you really really really really want to do a PGP signed
-patch, format it as "multipart/signed", not a text/plain message
-that starts with '-----BEGIN PGP SIGNED MESSAGE-----'.  That is
-not a text/plain, it's something else.
-
-Note that your maintainer does not necessarily read everything
-on the git mailing list.  If your patch is for discussion first,
-send it "To:" the mailing list, and optionally "cc:" him.  If it
-is trivially correct or after the list reached a consensus, send
-it "To:" the maintainer and optionally "cc:" the list.
-
-Also note that your maintainer does not actively involve himself in
-maintaining what are in contrib/ hierarchy.  When you send fixes and
-enhancements to them, do not forget to "cc: " the person who primarily
-worked on that hierarchy in contrib/.
-
-
-(4) Sign your work
-
-To improve tracking of who did what, we've borrowed the
-"sign-off" procedure from the Linux kernel project on patches
-that are being emailed around.  Although core GIT is a lot
-smaller project it is a good discipline to follow it.
-
-The sign-off is a simple line at the end of the explanation for
-the patch, which certifies that you wrote it or otherwise have
-the right to pass it on as a open-source patch.  The rules are
-pretty simple: if you can certify the below:
-
-        Developer's Certificate of Origin 1.1
-
-        By making a contribution to this project, I certify that:
-
-        (a) The contribution was created in whole or in part by me and I
-            have the right to submit it under the open source license
-            indicated in the file; or
-
-        (b) The contribution is based upon previous work that, to the best
-            of my knowledge, is covered under an appropriate open source
-            license and I have the right under that license to submit that
-            work with modifications, whether created in whole or in part
-            by me, under the same open source license (unless I am
-            permitted to submit under a different license), as indicated
-            in the file; or
-
-        (c) The contribution was provided directly to me by some other
-            person who certified (a), (b) or (c) and I have not modified
-            it.
-
-	(d) I understand and agree that this project and the contribution
-	    are public and that a record of the contribution (including all
-	    personal information I submit with it, including my sign-off) is
-	    maintained indefinitely and may be redistributed consistent with
-	    this project or the open source license(s) involved.
-
-then you just add a line saying
-
-	Signed-off-by: Random J Developer <random@developer.example.org>
-
-This line can be automatically added by git if you run the git-commit
-command with the -s option.
-
-Some people also put extra tags at the end.  They'll just be ignored for
-now, but you can do this to mark internal company procedures or just
-point out some special detail about the sign-off.
-
-
-------------------------------------------------
-MUA specific hints
-
-Some of patches I receive or pick up from the list share common
-patterns of breakage.  Please make sure your MUA is set up
-properly not to corrupt whitespaces.  Here are two common ones
-I have seen:
-
-* Empty context lines that do not have _any_ whitespace.
-
-* Non empty context lines that have one extra whitespace at the
-  beginning.
-
-One test you could do yourself if your MUA is set up correctly is:
-
-* Send the patch to yourself, exactly the way you would, except
-  To: and Cc: lines, which would not contain the list and
-  maintainer address.
-
-* Save that patch to a file in UNIX mailbox format.  Call it say
-  a.patch.
-
-* Try to apply to the tip of the "master" branch from the
-  git.git public repository:
-
-    $ git fetch http://kernel.org/pub/scm/git/git.git master:test-apply
-    $ git checkout test-apply
-    $ git reset --hard
-    $ git am a.patch
-
-If it does not apply correctly, there can be various reasons.
-
-* Your patch itself does not apply cleanly.  That is _bad_ but
-  does not have much to do with your MUA.  Please rebase the
-  patch appropriately.
-
-* Your MUA corrupted your patch; "am" would complain that
-  the patch does not apply.  Look at .dotest/ subdirectory and
-  see what 'patch' file contains and check for the common
-  corruption patterns mentioned above.
-
-* While you are at it, check what are in 'info' and
-  'final-commit' files as well.  If what is in 'final-commit' is
-  not exactly what you would want to see in the commit log
-  message, it is very likely that your maintainer would end up
-  hand editing the log message when he applies your patch.
-  Things like "Hi, this is my first patch.\n", if you really
-  want to put in the patch e-mail, should come after the
-  three-dash line that signals the end of the commit message.
-
-
-Pine
-----
-
-(Johannes Schindelin)
-
-I don't know how many people still use pine, but for those poor
-souls it may be good to mention that the quell-flowed-text is
-needed for recent versions.
-
-... the "no-strip-whitespace-before-send" option, too. AFAIK it
-was introduced in 4.60.
-
-(Linus Torvalds)
-
-And 4.58 needs at least this.
-
----
-diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1)
-Author: Linus Torvalds <torvalds@g5.osdl.org>
-Date:   Mon Aug 15 17:23:51 2005 -0700
-
-    Fix pine whitespace-corruption bug
-
-    There's no excuse for unconditionally removing whitespace from
-    the pico buffers on close.
-
-diff --git a/pico/pico.c b/pico/pico.c
---- a/pico/pico.c
-+++ b/pico/pico.c
-@@ -219,7 +219,9 @@ PICO *pm;
-	    switch(pico_all_done){	/* prepare for/handle final events */
-	      case COMP_EXIT :		/* already confirmed */
-		packheader();
-+#if 0
-		stripwhitespace();
-+#endif
-		c |= COMP_EXIT;
-		break;
-
-
-(Daniel Barkalow)
-
-> A patch to SubmittingPatches, MUA specific help section for
-> users of Pine 4.63 would be very much appreciated.
-
-Ah, it looks like a recent version changed the default behavior to do the
-right thing, and inverted the sense of the configuration option. (Either
-that or Gentoo did it.) So you need to set the
-"no-strip-whitespace-before-send" option, unless the option you have is
-"strip-whitespace-before-send", in which case you should avoid checking
-it.
-
-
-Thunderbird
------------
-
-(A Large Angry SCM)
-
-Here are some hints on how to successfully submit patches inline using
-Thunderbird.
-
-This recipe appears to work with the current [*1*] Thunderbird from Suse.
-
-The following Thunderbird extensions are needed:
-	AboutConfig 0.5
-		http://aboutconfig.mozdev.org/
-	External Editor 0.7.2
-		http://globs.org/articles.php?lng=en&pg=8
-
-1) Prepare the patch as a text file using your method of choice.
-
-2) Before opening a compose window, use Edit->Account Settings to
-uncheck the "Compose messages in HTML format" setting in the
-"Composition & Addressing" panel of the account to be used to send the
-patch. [*2*]
-
-3) In the main Thunderbird window, _before_ you open the compose window
-for the patch, use Tools->about:config to set the following to the
-indicated values:
-	mailnews.send_plaintext_flowed	=> false
-	mailnews.wraplength		=> 0
-
-4) Open a compose window and click the external editor icon.
-
-5) In the external editor window, read in the patch file and exit the
-editor normally.
-
-6) Back in the compose window: Add whatever other text you wish to the
-message, complete the addressing and subject fields, and press send.
-
-7) Optionally, undo the about:config/account settings changes made in
-steps 2 & 3.
-
-
-[Footnotes]
-*1* Version 1.0 (20041207) from the MozillaThunderbird-1.0-5 rpm of Suse
-9.3 professional updates.
-
-*2* It may be possible to do this with about:config and the following
-settings but I haven't tried, yet.
-	mail.html_compose			=> false
-	mail.identity.default.compose_html	=> false
-	mail.identity.id?.compose_html		=> false
-
-
-Gnus
-----
-
-'|' in the *Summary* buffer can be used to pipe the current
-message to an external program, and this is a handy way to drive
-"git am".  However, if the message is MIME encoded, what is
-piped into the program is the representation you see in your
-*Article* buffer after unwrapping MIME.  This is often not what
-you would want for two reasons.  It tends to screw up non ASCII
-characters (most notably in people's names), and also
-whitespaces (fatal in patches).  Running 'C-u g' to display the
-message in raw form before using '|' to run the pipe can work
-this problem around.
-
-
-KMail
------
-
-This should help you to submit patches inline using KMail.
-
-1) Prepare the patch as a text file.
-
-2) Click on New Mail.
-
-3) Go under "Options" in the Composer window and be sure that
-"Word wrap" is not set.
-
-4) Use Message -> Insert file... and insert the patch.
-
-5) Back in the compose window: add whatever other text you wish to the
-message, complete the addressing and subject fields, and press send.

Documentation/asciidoc.conf

@@ -1,66 +0,0 @@
-## linkgit: macro
-#
-# Usage: linkgit:command[manpage-section]
-#
-# Note, {0} is the manpage section, while {target} is the command.
-#
-# Show GIT link as: <command>(<section>); if section is defined, else just show
-# the command.
-
-[attributes]
-plus=&#43;
-caret=&#94;
-startsb=&#91;
-endsb=&#93;
-tilde=&#126;
-
-ifdef::backend-docbook[]
-[linkgit-inlinemacro]
-{0%{target}}
-{0#<citerefentry>}
-{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>}
-{0#</citerefentry>}
-endif::backend-docbook[]
-
-ifdef::backend-docbook[]
-ifndef::docbook-xsl-172[]
-# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this.
-# v1.72 breaks with this because it replaces dots not in roff requests.
-[listingblock]
-<example><title>{title}</title>
-<literallayout>
-ifdef::doctype-manpage[]
-&#10;.ft C&#10;
-endif::doctype-manpage[]
-|
-ifdef::doctype-manpage[]
-&#10;.ft&#10;
-endif::doctype-manpage[]
-</literallayout>
-{title#}</example>
-endif::docbook-xsl-172[]
-endif::backend-docbook[]
-
-ifdef::doctype-manpage[]
-ifdef::backend-docbook[]
-[header]
-template::[header-declarations]
-<refentry>
-<refmeta>
-<refentrytitle>{mantitle}</refentrytitle>
-<manvolnum>{manvolnum}</manvolnum>
-<refmiscinfo class="source">Git</refmiscinfo>
-<refmiscinfo class="version">{git_version}</refmiscinfo>
-<refmiscinfo class="manual">Git Manual</refmiscinfo>
-</refmeta>
-<refnamediv>
-  <refname>{manname}</refname>
-  <refpurpose>{manpurpose}</refpurpose>
-</refnamediv>
-endif::backend-docbook[]
-endif::doctype-manpage[]
-
-ifdef::backend-xhtml11[]
-[linkgit-inlinemacro]
-<a href="{target}.html">{target}{0?({0})}</a>
-endif::backend-xhtml11[]

Documentation/blame-options.txt

@@ -1,87 +0,0 @@
--b::
-	Show blank SHA-1 for boundary commits.  This can also
-	be controlled via the `blame.blankboundary` config option.
-
---root::
-	Do not treat root commits as boundaries.  This can also be
-	controlled via the `blame.showroot` config option.
-
---show-stats::
-	Include additional statistics at the end of blame output.
-
--L <start>,<end>::
-	Annotate only the given line range.  <start> and <end> can take
-	one of these forms:
-
-	- number
-+
-If <start> or <end> is a number, it specifies an
-absolute line number (lines count from 1).
-+
-
-- /regex/
-+
-This form will use the first line matching the given
-POSIX regex.  If <end> is a regex, it will search
-starting at the line given by <start>.
-+
-
-- +offset or -offset
-+
-This is only valid for <end> and will specify a number
-of lines before or after the line given by <start>.
-+
-
--l::
-	Show long rev (Default: off).
-
--t::
-	Show raw timestamp (Default: off).
-
--S <revs-file>::
-	Use revs from revs-file instead of calling linkgit:git-rev-list[1].
-
--p, --porcelain::
-	Show in a format designed for machine consumption.
-
---incremental::
-	Show the result incrementally in a format designed for
-	machine consumption.
-
---contents <file>::
-	When <rev> is not specified, the command annotates the
-	changes starting backwards from the working tree copy.
-	This flag makes the command pretend as if the working
-	tree copy has the contents of the named file (specify
-	`-` to make the command read from the standard input).
-
--M|<num>|::
-	Detect moving lines in the file as well.  When a commit
-	moves a block of lines in a file (e.g. the original file
-	has A and then B, and the commit changes it to B and
-	then A), traditional 'blame' algorithm typically blames
-	the lines that were moved up (i.e. B) to the parent and
-	assigns blame to the lines that were moved down (i.e. A)
-	to the child commit.  With this option, both groups of lines
-	are blamed on the parent.
-+
-<num> is optional but it is the lower bound on the number of
-alphanumeric characters that git must detect as moving
-within a file for it to associate those lines with the parent
-commit.
-
--C|<num>|::
-	In addition to `-M`, detect lines copied from other
-	files that were modified in the same commit.  This is
-	useful when you reorganize your program and move code
-	around across files.  When this option is given twice,
-	the command looks for copies from all other files in the
-	parent for the commit that creates the file in addition.
-+
-<num> is optional but it is the lower bound on the number of
-alphanumeric characters that git must detect as moving
-between files for it to associate those lines with the parent
-commit.
-
--h, --help::
-	Show help message.

Documentation/build-docdep.perl

@@ -1,46 +0,0 @@
-#!/usr/bin/perl
-
-my %include = ();
-my %included = ();
-
-for my $text (<*.txt>) {
-    open I, '<', $text || die "cannot read: $text";
-    while (<I>) {
-	if (/^include::/) {
-	    chomp;
-	    s/^include::\s*//;
-	    s/\[\]//;
-	    $include{$text}{$_} = 1;
-	    $included{$_} = 1;
-	}
-    }
-    close I;
-}
-
-# Do we care about chained includes???
-my $changed = 1;
-while ($changed) {
-    $changed = 0;
-    while (my ($text, $included) = each %include) {
-	for my $i (keys %$included) {
-	    # $text has include::$i; if $i includes $j
-	    # $text indirectly includes $j.
-	    if (exists $include{$i}) {
-		for my $j (keys %{$include{$i}}) {
-		    if (!exists $include{$text}{$j}) {
-			$include{$text}{$j} = 1;
-			$included{$j} = 1;
-			$changed = 1;
-		    }
-		}
-	    }
-	}
-    }
-}
-
-while (my ($text, $included) = each %include) {
-    if (! exists $included{$text} &&
-	(my $base = $text) =~ s/\.txt$//) {
-	print "$base.html $base.xml : ", join(" ", keys %$included), "\n";
-    }
-}

Documentation/callouts.xsl

@@ -1,30 +0,0 @@
-<!-- callout.xsl: converts asciidoc callouts to man page format -->
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
-<xsl:template match="co">
-	<xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/>
-</xsl:template>
-<xsl:template match="calloutlist">
-	<xsl:text>.sp&#10;</xsl:text>
-	<xsl:apply-templates/>
-	<xsl:text>&#10;</xsl:text>
-</xsl:template>
-<xsl:template match="callout">
-	<xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/>
-	<xsl:apply-templates/>
-	<xsl:text>.br&#10;</xsl:text>
-</xsl:template>
-
-<!-- sorry, this is not about callouts, but attempts to work around
- spurious .sp at the tail of the line docbook stylesheets seem to add -->
-<xsl:template match="simpara">
-  <xsl:variable name="content">
-    <xsl:apply-templates/>
-  </xsl:variable>
-  <xsl:value-of select="normalize-space($content)"/>
-  <xsl:if test="not(ancestor::authorblurb) and
-                not(ancestor::personblurb)">
-    <xsl:text>&#10;&#10;</xsl:text>
-  </xsl:if>
-</xsl:template>
-
-</xsl:stylesheet>

Documentation/cat-texi.perl

@@ -1,38 +0,0 @@
-#!/usr/bin/perl -w
-
-my @menu = ();
-my $output = $ARGV[0];
-
-open TMP, '>', "$output.tmp";
-
-while (<STDIN>) {
-	next if (/^\\input texinfo/../\@node Top/);
-	next if (/^\@bye/ || /^\.ft/);
-	if (s/^\@top (.*)/\@node $1,,,Top/) {
-		push @menu, $1;
-	}
-	s/\(\@pxref{\[URLS\]}\)//;
-	print TMP;
-}
-close TMP;
-
-printf '\input texinfo
-@setfilename gitman.info
-@documentencoding us-ascii
-@node Top,,%s
-@top Git Manual Pages
-@documentlanguage en
-@menu
-', $menu[0];
-
-for (@menu) {
-	print "* ${_}::\n";
-}
-print "\@end menu\n";
-open TMP, '<', "$output.tmp";
-while (<TMP>) {
-	print;
-}
-close TMP;
-print "\@bye\n";
-unlink "$output.tmp";

Documentation/cmd-list.perl

@@ -1,74 +0,0 @@
-#!/usr/bin/perl -w
-
-use File::Compare qw(compare);
-
-sub format_one {
-	my ($out, $nameattr) = @_;
-	my ($name, $attr) = @$nameattr;
-	my ($state, $description);
-	$state = 0;
-	open I, '<', "$name.txt" or die "No such file $name.txt";
-	while (<I>) {
-		if (/^NAME$/) {
-			$state = 1;
-			next;
-		}
-		if ($state == 1 && /^----$/) {
-			$state = 2;
-			next;
-		}
-		next if ($state != 2);
-		chomp;
-		$description = $_;
-		last;
-	}
-	close I;
-	if (!defined $description) {
-		die "No description found in $name.txt";
-	}
-	if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {
-		print $out "linkgit:$name\[1\]::\n\t";
-		if ($attr =~ / deprecated /) {
-			print $out "(deprecated) ";
-		}
-		print $out "$text.\n\n";
-	}
-	else {
-		die "Description does not match $name: $description";
-	}
-}
-
-my %cmds = ();
-for (sort <>) {
-	next if /^#/;
-
-	chomp;
-	my ($name, $cat, $attr) = /^(\S+)\s+(.*?)(?:\s+(.*))?$/;
-	$attr = '' unless defined $attr;
-	push @{$cmds{$cat}}, [$name, " $attr "];
-}
-
-for my $cat (qw(ancillaryinterrogators
-		ancillarymanipulators
-		mainporcelain
-		plumbinginterrogators
-		plumbingmanipulators
-		synchingrepositories
-		foreignscminterface
-		purehelpers
-		synchelpers)) {
-	my $out = "cmds-$cat.txt";
-	open O, '>', "$out+" or die "Cannot open output file $out+";
-	for (@{$cmds{$cat}}) {
-		format_one(\*O, $_);
-	}
-	close O;
-
-	if (-f "$out" && compare("$out", "$out+") == 0) {
-		unlink "$out+";
-	}
-	else {
-		print STDERR "$out\n";
-		rename "$out+", "$out";
-	}
-}

Documentation/config.txt

@@ -1,887 +0,0 @@
-CONFIGURATION FILE
-------------------
-
-The git configuration file contains a number of variables that affect
-the git command's behavior. `.git/config` file for each repository
-is used to store the information for that repository, and
-`$HOME/.gitconfig` is used to store per user information to give
-fallback values for `.git/config` file. The file `/etc/gitconfig`
-can be used to store system-wide defaults.
-
-They can be used by both the git plumbing
-and the porcelains. The variables are divided into sections, where
-in the fully qualified variable name the variable itself is the last
-dot-separated segment and the section name is everything before the last
-dot. The variable names are case-insensitive and only alphanumeric
-characters are allowed. Some variables may appear multiple times.
-
-Syntax
-~~~~~~
-
-The syntax is fairly flexible and permissive; whitespaces are mostly
-ignored.  The '#' and ';' characters begin comments to the end of line,
-blank lines are ignored.
-
-The file consists of sections and variables.  A section begins with
-the name of the section in square brackets and continues until the next
-section begins.  Section names are not case sensitive.  Only alphanumeric
-characters, '`-`' and '`.`' are allowed in section names.  Each variable
-must belong to some section, which means that there must be section
-header before first setting of a variable.
-
-Sections can be further divided into subsections.  To begin a subsection
-put its name in double quotes, separated by space from the section name,
-in the section header, like in example below:
-
---------
-	[section "subsection"]
-
---------
-
-Subsection names can contain any characters except newline (doublequote
-'`"`' and backslash have to be escaped as '`\"`' and '`\\`',
-respectively) and are case sensitive.  Section header cannot span multiple
-lines.  Variables may belong directly to a section or to a given subsection.
-You can have `[section]` if you have `[section "subsection"]`, but you
-don't need to.
-
-There is also (case insensitive) alternative `[section.subsection]` syntax.
-In this syntax subsection names follow the same restrictions as for section
-name.
-
-All the other lines are recognized as setting variables, in the form
-'name = value'.  If there is no equal sign on the line, the entire line
-is taken as 'name' and the variable is recognized as boolean "true".
-The variable names are case-insensitive and only alphanumeric
-characters and '`-`' are allowed.  There can be more than one value
-for a given variable; we say then that variable is multivalued.
-
-Leading and trailing whitespace in a variable value is discarded.
-Internal whitespace within a variable value is retained verbatim.
-
-The values following the equals sign in variable assign are all either
-a string, an integer, or a boolean.  Boolean values may be given as yes/no,
-0/1 or true/false.  Case is not significant in boolean values, when
-converting value to the canonical form using '--bool' type specifier;
-`git-config` will ensure that the output is "true" or "false".
-
-String values may be entirely or partially enclosed in double quotes.
-You need to enclose variable value in double quotes if you want to
-preserve leading or trailing whitespace, or if variable value contains
-beginning of comment characters (if it contains '#' or ';').
-Double quote '`"`' and backslash '`\`' characters in variable value must
-be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
-
-The following escape sequences (beside '`\"`' and '`\\`') are recognized:
-'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)
-and '`\b`' for backspace (BS).  No other char escape sequence, nor octal
-char sequences are valid.
-
-Variable value ending in a '`\`' is continued on the next line in the
-customary UNIX fashion.
-
-Some variables may require special value format.
-
-Example
-~~~~~~~
-
-	# Core variables
-	[core]
-		; Don't trust file modes
-		filemode = false
-
-	# Our diff algorithm
-	[diff]
-		external = "/usr/local/bin/gnu-diff -u"
-		renames = true
-
-	[branch "devel"]
-		remote = origin
-		merge = refs/heads/devel
-
-	# Proxy settings
-	[core]
-		gitProxy="ssh" for "kernel.org"
-		gitProxy=default-proxy ; for the rest
-
-Variables
-~~~~~~~~~
-
-Note that this list is non-comprehensive and not necessarily complete.
-For command-specific variables, you will find a more detailed description
-in the appropriate manual page. You will find a description of non-core
-porcelain configuration variables in the respective porcelain documentation.
-
-core.fileMode::
-	If false, the executable bit differences between the index and
-	the working copy are ignored; useful on broken filesystems like FAT.
-	See linkgit:git-update-index[1]. True by default.
-
-core.quotepath::
-	The commands that output paths (e.g. `ls-files`,
-	`diff`), when not given the `-z` option, will quote
-	"unusual" characters in the pathname by enclosing the
-	pathname in a double-quote pair and with backslashes the
-	same way strings in C source code are quoted.  If this
-	variable is set to false, the bytes higher than 0x80 are
-	not quoted but output as verbatim.  Note that double
-	quote, backslash and control characters are always
-	quoted without `-z` regardless of the setting of this
-	variable.
-
-core.autocrlf::
-	If true, makes git convert `CRLF` at the end of lines in text files to
-	`LF` when reading from the filesystem, and convert in reverse when
-	writing to the filesystem.  The variable can be set to
-	'input', in which case the conversion happens only while
-	reading from the filesystem but files are written out with
-	`LF` at the end of lines.  Currently, which paths to consider
-	"text" (i.e. be subjected to the autocrlf mechanism) is
-	decided purely based on the contents.
-
-core.symlinks::
-	If false, symbolic links are checked out as small plain files that
-	contain the link text. linkgit:git-update-index[1] and
-	linkgit:git-add[1] will not change the recorded type to regular
-	file. Useful on filesystems like FAT that do not support
-	symbolic links. True by default.
-
-core.gitProxy::
-	A "proxy command" to execute (as 'command host port') instead
-	of establishing direct connection to the remote server when
-	using the git protocol for fetching. If the variable value is
-	in the "COMMAND for DOMAIN" format, the command is applied only
-	on hostnames ending with the specified domain string. This variable
-	may be set multiple times and is matched in the given order;
-	the first match wins.
-+
-Can be overridden by the 'GIT_PROXY_COMMAND' environment variable
-(which always applies universally, without the special "for"
-handling).
-
-core.ignoreStat::
-	The working copy files are assumed to stay unchanged until you
-	mark them otherwise manually - Git will not detect the file changes
-	by lstat() calls. This is useful on systems where those are very
-	slow, such as Microsoft Windows.  See linkgit:git-update-index[1].
-	False by default.
-
-core.preferSymlinkRefs::
-	Instead of the default "symref" format for HEAD
-	and other symbolic reference files, use symbolic links.
-	This is sometimes needed to work with old scripts that
-	expect HEAD to be a symbolic link.
-
-core.bare::
-	If true this repository is assumed to be 'bare' and has no
-	working directory associated with it.  If this is the case a
-	number of commands that require a working directory will be
-	disabled, such as linkgit:git-add[1] or linkgit:git-merge[1].
-+
-This setting is automatically guessed by linkgit:git-clone[1] or
-linkgit:git-init[1] when the repository was created.  By default a
-repository that ends in "/.git" is assumed to be not bare (bare =
-false), while all other repositories are assumed to be bare (bare
-= true).
-
-core.worktree::
-	Set the path to the working tree.  The value will not be
-	used in combination with repositories found automatically in
-	a .git directory (i.e. $GIT_DIR is not set).
-	This can be overridden by the GIT_WORK_TREE environment
-	variable and the '--work-tree' command line option.
-
-core.logAllRefUpdates::
-	Enable the reflog. Updates to a ref <ref> is logged to the file
-	"$GIT_DIR/logs/<ref>", by appending the new and old
-	SHA1, the date/time and the reason of the update, but
-	only when the file exists.  If this configuration
-	variable is set to true, missing "$GIT_DIR/logs/<ref>"
-	file is automatically created for branch heads.
-+
-This information can be used to determine what commit
-was the tip of a branch "2 days ago".
-+
-This value is true by default in a repository that has
-a working directory associated with it, and false by
-default in a bare repository.
-
-core.repositoryFormatVersion::
-	Internal variable identifying the repository format and layout
-	version.
-
-core.sharedRepository::
-	When 'group' (or 'true'), the repository is made shareable between
-	several users in a group (making sure all the files and objects are
-	group-writable). When 'all' (or 'world' or 'everybody'), the
-	repository will be readable by all users, additionally to being
-	group-shareable. When 'umask' (or 'false'), git will use permissions
-	reported by umask(2). See linkgit:git-init[1]. False by default.
-
-core.warnAmbiguousRefs::
-	If true, git will warn you if the ref name you passed it is ambiguous
-	and might match multiple refs in the .git/refs/ tree. True by default.
-
-core.compression::
-	An integer -1..9, indicating a default compression level.
-	-1 is the zlib default. 0 means no compression,
-	and 1..9 are various speed/size tradeoffs, 9 being slowest.
-	If set, this provides a default to other compression variables,
-	such as 'core.loosecompression' and 'pack.compression'.
-
-core.loosecompression::
-	An integer -1..9, indicating the compression level for objects that
-	are not in a pack file. -1 is the zlib default. 0 means no
-	compression, and 1..9 are various speed/size tradeoffs, 9 being
-	slowest.  If not set,  defaults to core.compression.  If that is
-	not set,  defaults to 1 (best speed).
-
-core.packedGitWindowSize::
-	Number of bytes of a pack file to map into memory in a
-	single mapping operation.  Larger window sizes may allow
-	your system to process a smaller number of large pack files
-	more quickly.  Smaller window sizes will negatively affect
-	performance due to increased calls to the operating system's
-	memory manager, but may improve performance when accessing
-	a large number of large pack files.
-+
-Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32
-MiB on 32 bit platforms and 1 GiB on 64 bit platforms.  This should
-be reasonable for all users/operating systems.  You probably do
-not need to adjust this value.
-+
-Common unit suffixes of 'k', 'm', or 'g' are supported.
-
-core.packedGitLimit::
-	Maximum number of bytes to map simultaneously into memory
-	from pack files.  If Git needs to access more than this many
-	bytes at once to complete an operation it will unmap existing
-	regions to reclaim virtual address space within the process.
-+
-Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.
-This should be reasonable for all users/operating systems, except on
-the largest projects.  You probably do not need to adjust this value.
-+
-Common unit suffixes of 'k', 'm', or 'g' are supported.
-
-core.deltaBaseCacheLimit::
-	Maximum number of bytes to reserve for caching base objects
-	that multiple deltafied objects reference.  By storing the
-	entire decompressed base objects in a cache Git is able
-	to avoid unpacking and decompressing frequently used base
-	objects multiple times.
-+
-Default is 16 MiB on all platforms.  This should be reasonable
-for all users/operating systems, except on the largest projects.
-You probably do not need to adjust this value.
-+
-Common unit suffixes of 'k', 'm', or 'g' are supported.
-
-core.excludesfile::
-	In addition to '.gitignore' (per-directory) and
-	'.git/info/exclude', git looks into this file for patterns
-	of files which are not meant to be tracked.  See
-	linkgit:gitignore[5].
-
-core.editor::
-	Commands such as `commit` and `tag` that lets you edit
-	messages by launching an editor uses the value of this
-	variable when it is set, and the environment variable
-	`GIT_EDITOR` is not set.  The order of preference is
-	`GIT_EDITOR` environment, `core.editor`, `VISUAL` and
-	`EDITOR` environment variables and then finally `vi`.
-
-core.pager::
-	The command that git will use to paginate output.  Can be overridden
-	with the `GIT_PAGER` environment variable.
-
-core.whitespace::
-	A comma separated list of common whitespace problems to
-	notice.  `git diff` will use `color.diff.whitespace` to
-	highlight them, and `git apply --whitespace=error` will
-	consider them as errors:
-+
-* `trailing-space` treats trailing whitespaces at the end of the line
-  as an error (enabled by default).
-* `space-before-tab` treats a space character that appears immediately
-  before a tab character in the initial indent part of the line as an
-  error (enabled by default).
-* `indent-with-non-tab` treats a line that is indented with 8 or more
-  space characters as an error (not enabled by default).
-
-alias.*::
-	Command aliases for the linkgit:git[1] command wrapper - e.g.
-	after defining "alias.last = cat-file commit HEAD", the invocation
-	"git last" is equivalent to "git cat-file commit HEAD". To avoid
-	confusion and troubles with script usage, aliases that
-	hide existing git commands are ignored. Arguments are split by
-	spaces, the usual shell quoting and escaping is supported.
-	quote pair and a backslash can be used to quote them.
-+
-If the alias expansion is prefixed with an exclamation point,
-it will be treated as a shell command.  For example, defining
-"alias.new = !gitk --all --not ORIG_HEAD", the invocation
-"git new" is equivalent to running the shell command
-"gitk --all --not ORIG_HEAD".
-
-apply.whitespace::
-	Tells `git-apply` how to handle whitespaces, in the same way
-	as the '--whitespace' option. See linkgit:git-apply[1].
-
-branch.autosetupmerge::
-	Tells `git-branch` and `git-checkout` to setup new branches
-	so that linkgit:git-pull[1] will appropriately merge from that
-	remote branch.  Note that even if this option is not set,
-	this behavior can be chosen per-branch using the `--track`
-	and `--no-track` options.  This option defaults to true.
-
-branch.<name>.remote::
-	When in branch <name>, it tells `git fetch` which remote to fetch.
-	If this option is not given, `git fetch` defaults to remote "origin".
-
-branch.<name>.merge::
-	When in branch <name>, it tells `git fetch` the default
-	refspec to be marked for merging in FETCH_HEAD. The value is
-	handled like the remote part of a refspec, and must match a
-	ref which is fetched from the remote given by
-	"branch.<name>.remote".
-	The merge information is used by `git pull` (which at first calls
-	`git fetch`) to lookup the default branch for merging. Without
-	this option, `git pull` defaults to merge the first refspec fetched.
-	Specify multiple values to get an octopus merge.
-	If you wish to setup `git pull` so that it merges into <name> from
-	another branch in the local repository, you can point
-	branch.<name>.merge to the desired branch, and use the special setting
-	`.` (a period) for branch.<name>.remote.
-
-branch.<name>.mergeoptions::
-	Sets default options for merging into branch <name>. The syntax and
-	supported options are equal to that of linkgit:git-merge[1], but
-	option values containing whitespace characters are currently not
-	supported.
-
-branch.<name>.rebase::
-	When true, rebase the branch <name> on top of the fetched branch,
-	instead of merging the default branch from the default remote.
-	*NOTE*: this is a possibly dangerous operation; do *not* use
-	it unless you understand the implications (see linkgit:git-rebase[1]
-	for details).
-
-browser.<tool>.path::
-	Override the path for the given tool that may be used to
-	browse HTML help (see '-w' option in linkgit:git-help[1]) or a
-	working repository in gitweb (see linkgit:git-instaweb[1]).
-
-clean.requireForce::
-	A boolean to make git-clean do nothing unless given -f
-	or -n.   Defaults to true.
-
-color.branch::
-	A boolean to enable/disable color in the output of
-	linkgit:git-branch[1]. May be set to `always`,
-	`false` (or `never`) or `auto` (or `true`), in which case colors are used
-	only when the output is to a terminal. Defaults to false.
-
-color.branch.<slot>::
-	Use customized color for branch coloration. `<slot>` is one of
-	`current` (the current branch), `local` (a local branch),
-	`remote` (a tracking branch in refs/remotes/), `plain` (other
-	refs).
-+
-The value for these configuration variables is a list of colors (at most
-two) and attributes (at most one), separated by spaces.  The colors
-accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,
-`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,
-`blink` and `reverse`.  The first color given is the foreground; the
-second is the background.  The position of the attribute, if any,
-doesn't matter.
-
-color.diff::
-	When set to `always`, always use colors in patch.
-	When false (or `never`), never.  When set to `true` or `auto`, use
-	colors only when the output is to the terminal. Defaults to false.
-
-color.diff.<slot>::
-	Use customized color for diff colorization.  `<slot>` specifies
-	which part of the patch to use the specified color, and is one
-	of `plain` (context text), `meta` (metainformation), `frag`
-	(hunk header), `old` (removed lines), `new` (added lines),
-	`commit` (commit headers), or `whitespace` (highlighting
-	whitespace errors). The values of these variables may be specified as
-	in color.branch.<slot>.
-
-color.interactive::
-	When set to `always`, always use colors for interactive prompts
-	and displays (such as those used by "git add --interactive").
-	When false (or `never`), never.  When set to `true` or `auto`, use
-	colors only when the output is to the terminal. Defaults to false.
-
-color.interactive.<slot>::
-	Use customized color for `git add --interactive`
-	output. `<slot>` may be `prompt`, `header`, or `help`, for
-	three distinct types of normal output from interactive
-	programs.  The values of these variables may be specified as
-	in color.branch.<slot>.
-
-color.pager::
-	A boolean to enable/disable colored output when the pager is in
-	use (default is true).
-
-color.status::
-	A boolean to enable/disable color in the output of
-	linkgit:git-status[1]. May be set to `always`,
-	`false` (or `never`) or `auto` (or `true`), in which case colors are used
-	only when the output is to a terminal. Defaults to false.
-
-color.status.<slot>::
-	Use customized color for status colorization. `<slot>` is
-	one of `header` (the header text of the status message),
-	`added` or `updated` (files which are added but not committed),
-	`changed` (files which are changed but not added in the index),
-	or `untracked` (files which are not tracked by git). The values of
-	these variables may be specified as in color.branch.<slot>.
-
-commit.template::
-	Specify a file to use as the template for new commit messages.
-
-diff.autorefreshindex::
-	When using `git diff` to compare with work tree
-	files, do not consider stat-only change as changed.
-	Instead, silently run `git update-index --refresh` to
-	update the cached stat information for paths whose
-	contents in the work tree match the contents in the
-	index.  This option defaults to true.  Note that this
-	affects only `git diff` Porcelain, and not lower level
-	`diff` commands, such as `git diff-files`.
-
-diff.external::
-	If this config variable is set, diff generation is not
-	performed using the internal diff machinery, but using the
-	given command.  Note: if you want to use an external diff
-	program only on a subset of your files, you might want to
-	use linkgit:gitattributes[5] instead.
-
-diff.renameLimit::
-	The number of files to consider when performing the copy/rename
-	detection; equivalent to the git diff option '-l'.
-
-diff.renames::
-	Tells git to detect renames.  If set to any boolean value, it
-	will enable basic rename detection.  If set to "copies" or
-	"copy", it will detect copies, as well.
-
-fetch.unpackLimit::
-	If the number of objects fetched over the git native
-	transfer is below this
-	limit, then the objects will be unpacked into loose object
-	files. However if the number of received objects equals or
-	exceeds this limit then the received pack will be stored as
-	a pack, after adding any missing delta bases.  Storing the
-	pack from a push can make the push operation complete faster,
-	especially on slow filesystems.  If not set, the value of
-	`transfer.unpackLimit` is used instead.
-
-format.numbered::
-	A boolean which can enable sequence numbers in patch subjects.
-	Setting this option to "auto" will enable it only if there is
-	more than one patch.  See --numbered option in
-	linkgit:git-format-patch[1].
-
-format.headers::
-	Additional email headers to include in a patch to be submitted
-	by mail.  See linkgit:git-format-patch[1].
-
-format.suffix::
-	The default for format-patch is to output files with the suffix
-	`.patch`. Use this variable to change that suffix (make sure to
-	include the dot if you want it).
-
-gc.aggressiveWindow::
-	The window size parameter used in the delta compression
-	algorithm used by 'git gc --aggressive'.  This defaults
-	to 10.
-
-gc.auto::
-	When there are approximately more than this many loose
-	objects in the repository, `git gc --auto` will pack them.
-	Some Porcelain commands use this command to perform a
-	light-weight garbage collection from time to time.  The
-	default value is 6700.  Setting this to 0 disables it.
-
-gc.autopacklimit::
-	When there are more than this many packs that are not
-	marked with `*.keep` file in the repository, `git gc
-	--auto` consolidates them into one larger pack.  The
-	default	value is 20.  Setting this to 0 disables it.
-
-gc.packrefs::
-	`git gc` does not run `git pack-refs` in a bare repository by
-	default so that older dumb-transport clients can still fetch
-	from the repository.  Setting this to `true` lets `git
-	gc` to run `git pack-refs`.  Setting this to `false` tells
-	`git gc` never to run `git pack-refs`. The default setting is
-	`notbare`. Enable it only when you know you do not have to
-	support such clients.  The default setting will change to `true`
-	at some stage, and setting this to `false` will continue to
-	prevent `git pack-refs` from being run from `git gc`.
-
-gc.reflogexpire::
-	`git reflog expire` removes reflog entries older than
-	this time; defaults to 90 days.
-
-gc.reflogexpireunreachable::
-	`git reflog expire` removes reflog entries older than
-	this time and are not reachable from the current tip;
-	defaults to 30 days.
-
-gc.rerereresolved::
-	Records of conflicted merge you resolved earlier are
-	kept for this many days when `git rerere gc` is run.
-	The default is 60 days.  See linkgit:git-rerere[1].
-
-gc.rerereunresolved::
-	Records of conflicted merge you have not resolved are
-	kept for this many days when `git rerere gc` is run.
-	The default is 15 days.  See linkgit:git-rerere[1].
-
-rerere.enabled::
-	Activate recording of resolved conflicts, so that identical
-	conflict hunks can be resolved automatically, should they
-	be encountered again.  linkgit:git-rerere[1] command is by
-	default enabled if you create `rr-cache` directory under
-	`$GIT_DIR`, but can be disabled by setting this option to false.
-
-gitcvs.enabled::
-	Whether the CVS server interface is enabled for this repository.
-	See linkgit:git-cvsserver[1].
-
-gitcvs.logfile::
-	Path to a log file where the CVS server interface well... logs
-	various stuff. See linkgit:git-cvsserver[1].
-
-gitcvs.allbinary::
-	If true, all files are sent to the client in mode '-kb'. This
-	causes the client to treat all files as binary files which suppresses
-	any newline munging it otherwise might do. A work-around for the
-	fact that there is no way yet to set single files to mode '-kb'.
-
-gitcvs.dbname::
-	Database used by git-cvsserver to cache revision information
-	derived from the git repository. The exact meaning depends on the
-	used database driver, for SQLite (which is the default driver) this
-	is a filename. Supports variable substitution (see
-	linkgit:git-cvsserver[1] for details). May not contain semicolons (`;`).
-	Default: '%Ggitcvs.%m.sqlite'
-
-gitcvs.dbdriver::
-	Used Perl DBI driver. You can specify any available driver
-        for this here, but it might not work. git-cvsserver is tested
-	with 'DBD::SQLite', reported to work with 'DBD::Pg', and
-	reported *not* to work with 'DBD::mysql'. Experimental feature.
-	May not contain double colons (`:`). Default: 'SQLite'.
-	See linkgit:git-cvsserver[1].
-
-gitcvs.dbuser, gitcvs.dbpass::
-	Database user and password. Only useful if setting 'gitcvs.dbdriver',
-	since SQLite has no concept of database users and/or passwords.
-	'gitcvs.dbuser' supports variable substitution (see
-	linkgit:git-cvsserver[1] for details).
-
-All gitcvs variables except for 'gitcvs.allbinary' can also be
-specified as 'gitcvs.<access_method>.<varname>' (where 'access_method'
-is one of "ext" and "pserver") to make them apply only for the given
-access method.
-
-help.browser::
-	Specify the browser that will be used to display help in the
-	'web' format. See linkgit:git-help[1].
-
-help.format::
-	Override the default help format used by linkgit:git-help[1].
-	Values 'man', 'info', 'web' and 'html' are supported. 'man' is
-	the default. 'web' and 'html' are the same.
-
-http.proxy::
-	Override the HTTP proxy, normally configured using the 'http_proxy'
-	environment variable (see linkgit:curl[1]).  This can be overridden
-	on a per-remote basis; see remote.<name>.proxy
-
-http.sslVerify::
-	Whether to verify the SSL certificate when fetching or pushing
-	over HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment
-	variable.
-
-http.sslCert::
-	File containing the SSL certificate when fetching or pushing
-	over HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment
-	variable.
-
-http.sslKey::
-	File containing the SSL private key when fetching or pushing
-	over HTTPS. Can be overridden by the 'GIT_SSL_KEY' environment
-	variable.
-
-http.sslCAInfo::
-	File containing the certificates to verify the peer with when
-	fetching or pushing over HTTPS. Can be overridden by the
-	'GIT_SSL_CAINFO' environment variable.
-
-http.sslCAPath::
-	Path containing files with the CA certificates to verify the peer
-	with when fetching or pushing over HTTPS. Can be overridden
-	by the 'GIT_SSL_CAPATH' environment variable.
-
-http.maxRequests::
-	How many HTTP requests to launch in parallel. Can be overridden
-	by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
-
-http.lowSpeedLimit, http.lowSpeedTime::
-	If the HTTP transfer speed is less than 'http.lowSpeedLimit'
-	for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
-	Can be overridden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and
-	'GIT_HTTP_LOW_SPEED_TIME' environment variables.
-
-http.noEPSV::
-	A boolean which disables using of EPSV ftp command by curl.
-	This can helpful with some "poor" ftp servers which don't
-	support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'
-	environment variable. Default is false (curl will use EPSV).
-
-i18n.commitEncoding::
-	Character encoding the commit messages are stored in; git itself
-	does not care per se, but this information is necessary e.g. when
-	importing commits from emails or in the gitk graphical history
-	browser (and possibly at other places in the future or in other
-	porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'.
-
-i18n.logOutputEncoding::
-	Character encoding the commit messages are converted to when
-	running `git-log` and friends.
-
-instaweb.browser::
-	Specify the program that will be used to browse your working
-	repository in gitweb. See linkgit:git-instaweb[1].
-
-instaweb.httpd::
-	The HTTP daemon command-line to start gitweb on your working
-	repository. See linkgit:git-instaweb[1].
-
-instaweb.local::
-	If true the web server started by linkgit:git-instaweb[1] will
-	be bound to the local IP (127.0.0.1).
-
-instaweb.modulepath::
-	The module path for an apache httpd used by linkgit:git-instaweb[1].
-
-instaweb.port::
-	The port number to bind the gitweb httpd to. See
-	linkgit:git-instaweb[1].
-
-log.showroot::
-	If true, the initial commit will be shown as a big creation event.
-	This is equivalent to a diff against an empty tree.
-	Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
-	normally hide the root commit will now show it. True by default.
-
-merge.summary::
-	Whether to include summaries of merged commits in newly created
-	merge commit messages. False by default.
-
-merge.tool::
-	Controls which merge resolution program is used by
-	linkgit:git-mergetool[1].  Valid values are: "kdiff3", "tkdiff",
-	"meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and "opendiff".
-
-merge.verbosity::
-	Controls the amount of output shown by the recursive merge
-	strategy.  Level 0 outputs nothing except a final error
-	message if conflicts were detected. Level 1 outputs only
-	conflicts, 2 outputs conflicts and file changes.  Level 5 and
-	above outputs debugging information.  The default is level 2.
-	Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
-
-merge.<driver>.name::
-	Defines a human readable name for a custom low-level
-	merge driver.  See linkgit:gitattributes[5] for details.
-
-merge.<driver>.driver::
-	Defines the command that implements a custom low-level
-	merge driver.  See linkgit:gitattributes[5] for details.
-
-merge.<driver>.recursive::
-	Names a low-level merge driver to be used when
-	performing an internal merge between common ancestors.
-	See linkgit:gitattributes[5] for details.
-
-mergetool.<tool>.path::
-	Override the path for the given tool.  This is useful in case
-	your tool is not in the PATH.
-
-pack.window::
-	The size of the window used by linkgit:git-pack-objects[1] when no
-	window size is given on the command line. Defaults to 10.
-
-pack.depth::
-	The maximum delta depth used by linkgit:git-pack-objects[1] when no
-	maximum depth is given on the command line. Defaults to 50.
-
-pack.windowMemory::
-	The window memory size limit used by linkgit:git-pack-objects[1]
-	when no limit is given on the command line.  The value can be
-	suffixed with "k", "m", or "g".  Defaults to 0, meaning no
-	limit.
-
-pack.compression::
-	An integer -1..9, indicating the compression level for objects
-	in a pack file. -1 is the zlib default. 0 means no
-	compression, and 1..9 are various speed/size tradeoffs, 9 being
-	slowest.  If not set,  defaults to core.compression.  If that is
-	not set,  defaults to -1, the zlib default, which is "a default
-	compromise between speed and compression (currently equivalent
-	to level 6)."
-
-pack.deltaCacheSize::
-	The maximum memory in bytes used for caching deltas in
-	linkgit:git-pack-objects[1].
-	A value of 0 means no limit. Defaults to 0.
-
-pack.deltaCacheLimit::
-	The maximum size of a delta, that is cached in
-	linkgit:git-pack-objects[1]. Defaults to 1000.
-
-pack.threads::
-	Specifies the number of threads to spawn when searching for best
-	delta matches.  This requires that linkgit:git-pack-objects[1]
-	be compiled with pthreads otherwise this option is ignored with a
-	warning. This is meant to reduce packing time on multiprocessor
-	machines. The required amount of memory for the delta search window
-	is however multiplied by the number of threads.
-
-pack.indexVersion::
-	Specify the default pack index version.  Valid values are 1 for
-	legacy pack index used by Git versions prior to 1.5.2, and 2 for
-	the new pack index with capabilities for packs larger than 4 GB
-	as well as proper protection against the repacking of corrupted
-	packs.  Version 2 is selected and this config option ignored
-	whenever the corresponding pack is larger than 2 GB.  Otherwise
-	the default is 1.
-
-pull.octopus::
-	The default merge strategy to use when pulling multiple branches
-	at once.
-
-pull.twohead::
-	The default merge strategy to use when pulling a single branch.
-
-remote.<name>.url::
-	The URL of a remote repository.  See linkgit:git-fetch[1] or
-	linkgit:git-push[1].
-
-remote.<name>.proxy::
-	For remotes that require curl (http, https and ftp), the URL to
-	the proxy to use for that remote.  Set to the empty string to
-	disable proxying for that remote.
-
-remote.<name>.fetch::
-	The default set of "refspec" for linkgit:git-fetch[1]. See
-	linkgit:git-fetch[1].
-
-remote.<name>.push::
-	The default set of "refspec" for linkgit:git-push[1]. See
-	linkgit:git-push[1].
-
-remote.<name>.skipDefaultUpdate::
-	If true, this remote will be skipped by default when updating
-	using the update subcommand of linkgit:git-remote[1].
-
-remote.<name>.receivepack::
-	The default program to execute on the remote side when pushing.  See
-	option \--exec of linkgit:git-push[1].
-
-remote.<name>.uploadpack::
-	The default program to execute on the remote side when fetching.  See
-	option \--exec of linkgit:git-fetch-pack[1].
-
-remote.<name>.tagopt::
-	Setting this value to --no-tags disables automatic tag following when fetching
-	from remote <name>
-
-remotes.<group>::
-	The list of remotes which are fetched by "git remote update
-	<group>".  See linkgit:git-remote[1].
-
-repack.usedeltabaseoffset::
-	Allow linkgit:git-repack[1] to create packs that uses
-	delta-base offset.  Defaults to false.
-
-show.difftree::
-	The default linkgit:git-diff-tree[1] arguments to be used
-	for linkgit:git-show[1].
-
-showbranch.default::
-	The default set of branches for linkgit:git-show-branch[1].
-	See linkgit:git-show-branch[1].
-
-status.relativePaths::
-	By default, linkgit:git-status[1] shows paths relative to the
-	current directory. Setting this variable to `false` shows paths
-	relative to the repository root (this was the default for git
-	prior to v1.5.4).
-
-tar.umask::
-	This variable can be used to restrict the permission bits of
-	tar archive entries.  The default is 0002, which turns off the
-	world write bit.  The special value "user" indicates that the
-	archiving user's umask will be used instead.  See umask(2) and
-	linkgit:git-archive[1].
-
-user.email::
-	Your email address to be recorded in any newly created commits.
-	Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and
-	'EMAIL' environment variables.  See linkgit:git-commit-tree[1].
-
-user.name::
-	Your full name to be recorded in any newly created commits.
-	Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
-	environment variables.  See linkgit:git-commit-tree[1].
-
-user.signingkey::
-	If linkgit:git-tag[1] is not selecting the key you want it to
-	automatically when creating a signed tag, you can override the
-	default selection with this variable.  This option is passed
-	unchanged to gpg's --local-user parameter, so you may specify a key
-	using any method that gpg supports.
-
-whatchanged.difftree::
-	The default linkgit:git-diff-tree[1] arguments to be used
-	for linkgit:git-whatchanged[1].
-
-imap::
-	The configuration variables in the 'imap' section are described
-	in linkgit:git-imap-send[1].
-
-receive.unpackLimit::
-	If the number of objects received in a push is below this
-	limit then the objects will be unpacked into loose object
-	files. However if the number of received objects equals or
-	exceeds this limit then the received pack will be stored as
-	a pack, after adding any missing delta bases.  Storing the
-	pack from a push can make the push operation complete faster,
-	especially on slow filesystems.  If not set, the value of
-	`transfer.unpackLimit` is used instead.
-
-receive.denyNonFastForwards::
-	If set to true, git-receive-pack will deny a ref update which is
-	not a fast forward. Use this to prevent such an update via a push,
-	even if that push is forced. This configuration variable is
-	set when initializing a shared repository.
-
-transfer.unpackLimit::
-	When `fetch.unpackLimit` or `receive.unpackLimit` are
-	not set, the value of this variable is used instead.
-	The default value is 100.
-
-web.browser::
-	Specify a web browser that may be used by some commands.
-	Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
-	may use it.

Documentation/cvs-migration.txt

@@ -1,171 +0,0 @@
-git for CVS users
-=================
-
-Git differs from CVS in that every working tree contains a repository with
-a full copy of the project history, and no repository is inherently more
-important than any other.  However, you can emulate the CVS model by
-designating a single shared repository which people can synchronize with;
-this document explains how to do that.
-
-Some basic familiarity with git is required.  This
-link:tutorial.html[tutorial introduction to git] should be sufficient.
-
-Developing against a shared repository
---------------------------------------
-
-Suppose a shared repository is set up in /pub/repo.git on the host
-foo.com.  Then as an individual committer you can clone the shared
-repository over ssh with:
-
-------------------------------------------------
-$ git clone foo.com:/pub/repo.git/ my-project
-$ cd my-project
-------------------------------------------------
-
-and hack away.  The equivalent of `cvs update` is
-
-------------------------------------------------
-$ git pull origin
-------------------------------------------------
-
-which merges in any work that others might have done since the clone
-operation.  If there are uncommitted changes in your working tree, commit
-them first before running git pull.
-
-[NOTE]
-================================
-The `pull` command knows where to get updates from because of certain
-configuration variables that were set by the first `git clone`
-command; see `git config -l` and the linkgit:git-config[1] man
-page for details.
-================================
-
-You can update the shared repository with your changes by first committing
-your changes, and then using the linkgit:git-push[1] command:
-
-------------------------------------------------
-$ git push origin master
-------------------------------------------------
-
-to "push" those commits to the shared repository.  If someone else has
-updated the repository more recently, `git push`, like `cvs commit`, will
-complain, in which case you must pull any changes before attempting the
-push again.
-
-In the `git push` command above we specify the name of the remote branch
-to update (`master`).  If we leave that out, `git push` tries to update
-any branches in the remote repository that have the same name as a branch
-in the local repository.  So the last `push` can be done with either of:
-
-------------
-$ git push origin
-$ git push foo.com:/pub/project.git/
-------------
-
-as long as the shared repository does not have any branches
-other than `master`.
-
-Setting Up a Shared Repository
-------------------------------
-
-We assume you have already created a git repository for your project,
-possibly created from scratch or from a tarball (see the
-link:tutorial.html[tutorial]), or imported from an already existing CVS
-repository (see the next section).
-
-Assume your existing repo is at /home/alice/myproject.  Create a new "bare"
-repository (a repository without a working tree) and fetch your project into
-it:
-
-------------------------------------------------
-$ mkdir /pub/my-repo.git
-$ cd /pub/my-repo.git
-$ git --bare init --shared
-$ git --bare fetch /home/alice/myproject master:master
-------------------------------------------------
-
-Next, give every team member read/write access to this repository.  One
-easy way to do this is to give all the team members ssh access to the
-machine where the repository is hosted.  If you don't want to give them a
-full shell on the machine, there is a restricted shell which only allows
-users to do git pushes and pulls; see linkgit:git-shell[1].
-
-Put all the committers in the same group, and make the repository
-writable by that group:
-
-------------------------------------------------
-$ chgrp -R $group /pub/my-repo.git
-------------------------------------------------
-
-Make sure committers have a umask of at most 027, so that the directories
-they create are writable and searchable by other group members.
-
-Importing a CVS archive
------------------------
-
-First, install version 2.1 or higher of cvsps from
-link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
-sure it is in your path.  Then cd to a checked out CVS working directory
-of the project you are interested in and run linkgit:git-cvsimport[1]:
-
--------------------------------------------
-$ git cvsimport -C <destination> <module>
--------------------------------------------
-
-This puts a git archive of the named CVS module in the directory
-<destination>, which will be created if necessary.
-
-The import checks out from CVS every revision of every file.  Reportedly
-cvsimport can average some twenty revisions per second, so for a
-medium-sized project this should not take more than a couple of minutes.
-Larger projects or remote repositories may take longer.
-
-The main trunk is stored in the git branch named `origin`, and additional
-CVS branches are stored in git branches with the same names.  The most
-recent version of the main trunk is also left checked out on the `master`
-branch, so you can start adding your own changes right away.
-
-The import is incremental, so if you call it again next month it will
-fetch any CVS updates that have been made in the meantime.  For this to
-work, you must not modify the imported branches; instead, create new
-branches for your own changes, and merge in the imported branches as
-necessary.
-
-Advanced Shared Repository Management
--------------------------------------
-
-Git allows you to specify scripts called "hooks" to be run at certain
-points.  You can use these, for example, to send all commits to the shared
-repository to a mailing list.  See link:hooks.html[Hooks used by git].
-
-You can enforce finer grained permissions using update hooks.  See
-link:howto/update-hook-example.txt[Controlling access to branches using
-update hooks].
-
-Providing CVS Access to a git Repository
-----------------------------------------
-
-It is also possible to provide true CVS access to a git repository, so
-that developers can still use CVS; see linkgit:git-cvsserver[1] for
-details.
-
-Alternative Development Models
-------------------------------
-
-CVS users are accustomed to giving a group of developers commit access to
-a common repository.  As we've seen, this is also possible with git.
-However, the distributed nature of git allows other development models,
-and you may want to first consider whether one of them might be a better
-fit for your project.
-
-For example, you can choose a single person to maintain the project's
-primary public repository.  Other developers then clone this repository
-and each work in their own clone.  When they have a series of changes that
-they're happy with, they ask the maintainer to pull from the branch
-containing the changes.  The maintainer reviews their changes and pulls
-them into the primary repository, which other developers pull from as
-necessary to stay coordinated.  The Linux kernel and other projects use
-variants of this model.
-
-With a small group, developers may just pull changes from each other's
-repositories without the need for a central maintainer.

Documentation/diff-format.txt

@@ -1,147 +0,0 @@
-The output format from "git-diff-index", "git-diff-tree",
-"git-diff-files" and "git diff --raw" are very similar.
-
-These commands all compare two sets of things; what is
-compared differs:
-
-git-diff-index <tree-ish>::
-        compares the <tree-ish> and the files on the filesystem.
-
-git-diff-index --cached <tree-ish>::
-        compares the <tree-ish> and the index.
-
-git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]::
-        compares the trees named by the two arguments.
-
-git-diff-files [<pattern>...]::
-        compares the index and the files on the filesystem.
-
-
-An output line is formatted this way:
-
-------------------------------------------------
-in-place edit  :100644 100644 bcd1234... 0123456... M file0
-copy-edit      :100644 100644 abcd123... 1234567... C68 file1 file2
-rename-edit    :100644 100644 abcd123... 1234567... R86 file1 file3
-create         :000000 100644 0000000... 1234567... A file4
-delete         :100644 000000 1234567... 0000000... D file5
-unmerged       :000000 000000 0000000... 0000000... U file6
-------------------------------------------------
-
-That is, from the left to the right:
-
-. a colon.
-. mode for "src"; 000000 if creation or unmerged.
-. a space.
-. mode for "dst"; 000000 if deletion or unmerged.
-. a space.
-. sha1 for "src"; 0\{40\} if creation or unmerged.
-. a space.
-. sha1 for "dst"; 0\{40\} if creation, unmerged or "look at work tree".
-. a space.
-. status, followed by optional "score" number.
-. a tab or a NUL when '-z' option is used.
-. path for "src"
-. a tab or a NUL when '-z' option is used; only exists for C or R.
-. path for "dst"; only exists for C or R.
-. an LF or a NUL when '-z' option is used, to terminate the record.
-
-<sha1> is shown as all 0's if a file is new on the filesystem
-and it is out of sync with the index.
-
-Example:
-
-------------------------------------------------
-:100644 100644 5be4a4...... 000000...... M file.c
-------------------------------------------------
-
-When `-z` option is not used, TAB, LF, and backslash characters
-in pathnames are represented as `\t`, `\n`, and `\\`,
-respectively.
-
-diff format for merges
-----------------------
-
-"git-diff-tree", "git-diff-files" and "git-diff --raw"
-can take '-c' or '--cc' option
-to generate diff output also for merge commits.  The output differs
-from the format described above in the following way:
-
-. there is a colon for each parent
-. there are more "src" modes and "src" sha1
-. status is concatenated status characters for each parent
-. no optional "score" number
-. single path, only for "dst"
-
-Example:
-
-------------------------------------------------
-::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM	describe.c
-------------------------------------------------
-
-Note that 'combined diff' lists only files which were modified from
-all parents.
-
-
-include::diff-generate-patch.txt[]
-
-
-other diff formats
-------------------
-
-The `--summary` option describes newly added, deleted, renamed and
-copied files.  The `--stat` option adds diffstat(1) graph to the
-output.  These options can be combined with other options, such as
-`-p`, and are meant for human consumption.
-
-When showing a change that involves a rename or a copy, `--stat` output
-formats the pathnames compactly by combining common prefix and suffix of
-the pathnames.  For example, a change that moves `arch/i386/Makefile` to
-`arch/x86/Makefile` while modifying 4 lines will be shown like this:
-
-------------------------------------
-arch/{i386 => x86}/Makefile    |   4 +--
-------------------------------------
-
-The `--numstat` option gives the diffstat(1) information but is designed
-for easier machine consumption.  An entry in `--numstat` output looks
-like this:
-
-----------------------------------------
-1	2	README
-3	1	arch/{i386 => x86}/Makefile
-----------------------------------------
-
-That is, from left to right:
-
-. the number of added lines;
-. a tab;
-. the number of deleted lines;
-. a tab;
-. pathname (possibly with rename/copy information);
-. a newline.
-
-When `-z` output option is in effect, the output is formatted this way:
-
-----------------------------------------
-1	2	README NUL
-3	1	NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
-----------------------------------------
-
-That is:
-
-. the number of added lines;
-. a tab;
-. the number of deleted lines;
-. a tab;
-. a NUL (only exists if renamed/copied);
-. pathname in preimage;
-. a NUL (only exists if renamed/copied);
-. pathname in postimage (only exists if renamed/copied);
-. a NUL.
-
-The extra `NUL` before the preimage path in renamed case is to allow
-scripts that read the output to tell if the current record being read is
-a single-path record or a rename/copy record without reading ahead.
-After reading added and deleted lines, reading up to `NUL` would yield
-the pathname, but if that is `NUL`, the record will show two paths.

Documentation/diff-generate-patch.txt

@@ -1,161 +0,0 @@
-Generating patches with -p
---------------------------
-
-When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
-with a '-p' option, "git diff" without the '--raw' option, or
-"git log" with the "-p" option, they
-do not produce the output described above; instead they produce a
-patch file.  You can customize the creation of such patches via the
-GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
-
-What the -p option produces is slightly different from the traditional
-diff format.
-
-1.   It is preceded with a "git diff" header, that looks like
-     this:
-
-       diff --git a/file1 b/file2
-+
-The `a/` and `b/` filenames are the same unless rename/copy is
-involved.  Especially, even for a creation or a deletion,
-`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
-+
-When rename/copy is involved, `file1` and `file2` show the
-name of the source file of the rename/copy and the name of
-the file that rename/copy produces, respectively.
-
-2.   It is followed by one or more extended header lines:
-
-       old mode <mode>
-       new mode <mode>
-       deleted file mode <mode>
-       new file mode <mode>
-       copy from <path>
-       copy to <path>
-       rename from <path>
-       rename to <path>
-       similarity index <number>
-       dissimilarity index <number>
-       index <hash>..<hash> <mode>
-
-3.  TAB, LF, double quote and backslash characters in pathnames
-    are represented as `\t`, `\n`, `\"` and `\\`, respectively.
-    If there is need for such substitution then the whole
-    pathname is put in double quotes.
-
-The similarity index is the percentage of unchanged lines, and
-the dissimilarity index is the percentage of changed lines.  It
-is a rounded down integer, followed by a percent sign.  The
-similarity index value of 100% is thus reserved for two equal
-files, while 100% dissimilarity means that no line from the old
-file made it into the new one.
-
-
-combined diff format
---------------------
-
-"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
-'--cc' option to produce 'combined diff'.  For showing a merge commit
-with "git log -p", this is the default format.
-A 'combined diff' format looks like this:
-
-------------
-diff --combined describe.c
-index fabadb8,cc95eb0..4866510
---- a/describe.c
-+++ b/describe.c
-@@@ -98,20 -98,12 +98,20 @@@
-	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
-  }
-
-- static void describe(char *arg)
- -static void describe(struct commit *cmit, int last_one)
-++static void describe(char *arg, int last_one)
-  {
- +	unsigned char sha1[20];
- +	struct commit *cmit;
-	struct commit_list *list;
-	static int initialized = 0;
-	struct commit_name *n;
-
- +	if (get_sha1(arg, sha1) < 0)
- +		usage(describe_usage);
- +	cmit = lookup_commit_reference(sha1);
- +	if (!cmit)
- +		usage(describe_usage);
- +
-	if (!initialized) {
-		initialized = 1;
-		for_each_ref(get_name);
-------------
-
-1.   It is preceded with a "git diff" header, that looks like
-     this (when '-c' option is used):
-
-       diff --combined file
-+
-or like this (when '--cc' option is used):
-
-       diff --c file
-
-2.   It is followed by one or more extended header lines
-     (this example shows a merge with two parents):
-
-       index <hash>,<hash>..<hash>
-       mode <mode>,<mode>..<mode>
-       new file mode <mode>
-       deleted file mode <mode>,<mode>
-+
-The `mode <mode>,<mode>..<mode>` line appears only if at least one of
-the <mode> is different from the rest. Extended headers with
-information about detected contents movement (renames and
-copying detection) are designed to work with diff of two
-<tree-ish> and are not used by combined diff format.
-
-3.   It is followed by two-line from-file/to-file header
-
-       --- a/file
-       +++ b/file
-+
-Similar to two-line header for traditional 'unified' diff
-format, `/dev/null` is used to signal created or deleted
-files.
-
-4.   Chunk header format is modified to prevent people from
-     accidentally feeding it to `patch -p1`. Combined diff format
-     was created for review of merge commit changes, and was not
-     meant for apply. The change is similar to the change in the
-     extended 'index' header:
-
-       @@@ <from-file-range> <from-file-range> <to-file-range> @@@
-+
-There are (number of parents + 1) `@` characters in the chunk
-header for combined diff format.
-
-Unlike the traditional 'unified' diff format, which shows two
-files A and B with a single column that has `-` (minus --
-appears in A but removed in B), `+` (plus -- missing in A but
-added to B), or `" "` (space -- unchanged) prefix, this format
-compares two or more files file1, file2,... with one file X, and
-shows how X differs from each of fileN.  One column for each of
-fileN is prepended to the output line to note how X's line is
-different from it.
-
-A `-` character in the column N means that the line appears in
-fileN but it does not appear in the result.  A `+` character
-in the column N means that the line appears in the last file,
-and fileN does not have that line (in other words, the line was
-added, from the point of view of that parent).
-
-In the above example output, the function signature was changed
-from both files (hence two `-` removals from both file1 and
-file2, plus `++` to mean one line that was added does not appear
-in either file1 nor file2).  Also two other lines are the same
-from file1 but do not appear in file2 (hence prefixed with ` +`).
-
-When shown by `git diff-tree -c`, it compares the parents of a
-merge commit with the merge result (i.e. file1..fileN are the
-parents).  When shown by `git diff-files -c`, it compares the
-two unresolved merge parents with the working tree file
-(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
-"their version").

Documentation/diff-options.txt

@@ -1,224 +0,0 @@
-// Please don't remove this comment as asciidoc behaves badly when
-// the first non-empty line is ifdef/ifndef. The symptom is that
-// without this comment the <git-diff-core> attribute conditionally
-// defined below ends up being defined unconditionally.
-// Last checked with asciidoc 7.0.2.
-
-ifndef::git-format-patch[]
-ifndef::git-diff[]
-ifndef::git-log[]
-:git-diff-core: 1
-endif::git-log[]
-endif::git-diff[]
-endif::git-format-patch[]
-
-ifdef::git-format-patch[]
--p::
-	Generate patches without diffstat.
-endif::git-format-patch[]
-
-ifndef::git-format-patch[]
--p::
-	Generate patch (see section on generating patches).
-	{git-diff? This is the default.}
-endif::git-format-patch[]
-
--u::
-	Synonym for "-p".
-
--U<n>::
-	Shorthand for "--unified=<n>".
-
---unified=<n>::
-	Generate diffs with <n> lines of context instead of
-	the usual three. Implies "-p".
-
---raw::
-	Generate the raw format.
-	{git-diff-core? This is the default.}
-
---patch-with-raw::
-	Synonym for "-p --raw".
-
---stat[=width[,name-width]]::
-	Generate a diffstat.  You can override the default
-	output width for 80-column terminal by "--stat=width".
-	The width of the filename part can be controlled by
-	giving another width to it separated by a comma.
-
---numstat::
-	Similar to \--stat, but shows number of added and
-	deleted lines in decimal notation and pathname without
-	abbreviation, to make it more machine friendly.  For
-	binary files, outputs two `-` instead of saying
-	`0 0`.
-
---shortstat::
-	Output only the last line of the --stat format containing total
-	number of modified files, as well as number of added and deleted
-	lines.
-
---summary::
-	Output a condensed summary of extended header information
-	such as creations, renames and mode changes.
-
---patch-with-stat::
-	Synonym for "-p --stat".
-	{git-format-patch? This is the default.}
-
--z::
-	NUL-line termination on output.  This affects the --raw
-	output field terminator.  Also output from commands such
-	as "git-log" will be delimited with NUL between commits.
-
---name-only::
-	Show only names of changed files.
-
---name-status::
-	Show only names and status of changed files.
-
---color::
-	Show colored diff.
-
---no-color::
-	Turn off colored diff, even when the configuration file
-	gives the default to color output.
-
---color-words::
-	Show colored word diff, i.e. color words which have changed.
-
---no-renames::
-	Turn off rename detection, even when the configuration
-	file gives the default to do so.
-
---check::
-	Warn if changes introduce trailing whitespace
-	or an indent that uses a space before a tab. Exits with
-	non-zero status if problems are found. Not compatible with
-	--exit-code.
-
---full-index::
-	Instead of the first handful characters, show full
-	object name of pre- and post-image blob on the "index"
-	line when generating a patch format output.
-
---binary::
-	In addition to --full-index, output "binary diff" that
-	can be applied with "git apply".
-
---abbrev[=<n>]::
-	Instead of showing the full 40-byte hexadecimal object
-	name in diff-raw format output and diff-tree header
-	lines, show only handful hexdigits prefix.  This is
-	independent of --full-index option above, which controls
-	the diff-patch output format.  Non default number of
-	digits can be specified with --abbrev=<n>.
-
--B::
-	Break complete rewrite changes into pairs of delete and create.
-
--M::
-	Detect renames.
-
--C::
-	Detect copies as well as renames.  See also `--find-copies-harder`.
-
---diff-filter=[ACDMRTUXB*]::
-	Select only files that are Added (`A`), Copied (`C`),
-	Deleted (`D`), Modified (`M`), Renamed (`R`), have their
-	type (mode) changed (`T`), are Unmerged (`U`), are
-	Unknown (`X`), or have had their pairing Broken (`B`).
-	Any combination of the filter characters may be used.
-	When `*` (All-or-none) is added to the combination, all
-	paths are selected if there is any file that matches
-	other criteria in the comparison; if there is no file
-	that matches other criteria, nothing is selected.
-
---find-copies-harder::
-	For performance reasons, by default, `-C` option finds copies only
-	if the original file of the copy was modified in the same
-	changeset.  This flag makes the command
-	inspect unmodified files as candidates for the source of
-	copy.  This is a very expensive operation for large
-	projects, so use it with caution.  Giving more than one
-	`-C` option has the same effect.
-
--l<num>::
-	-M and -C options require O(n^2) processing time where n
-	is the number of potential rename/copy targets.  This
-	option prevents rename/copy detection from running if
-	the number of rename/copy targets exceeds the specified
-	number.
-
--S<string>::
-	Look for differences that contain the change in <string>.
-
---pickaxe-all::
-	When -S finds a change, show all the changes in that
-	changeset, not just the files that contain the change
-	in <string>.
-
---pickaxe-regex::
-	Make the <string> not a plain string but an extended POSIX
-	regex to match.
-
--O<orderfile>::
-	Output the patch in the order specified in the
-	<orderfile>, which has one shell glob pattern per line.
-
--R::
-	Swap two inputs; that is, show differences from index or
-	on-disk file to tree contents.
-
---text::
-	Treat all files as text.
-
--a::
-	Shorthand for "--text".
-
---ignore-space-at-eol::
-	Ignore changes in whitespace at EOL.
-
---ignore-space-change::
-	Ignore changes in amount of whitespace.  This ignores whitespace
-	at line end, and considers all other sequences of one or
-	more whitespace characters to be equivalent.
-
--b::
-	Shorthand for "--ignore-space-change".
-
---ignore-all-space::
-	Ignore whitespace when comparing lines.  This ignores
-	differences even if one line has whitespace where the other
-	line has none.
-
--w::
-	Shorthand for "--ignore-all-space".
-
---exit-code::
-	Make the program exit with codes similar to diff(1).
-	That is, it exits with 1 if there were differences and
-	0 means no differences.
-
---quiet::
-	Disable all output of the program. Implies --exit-code.
-
---ext-diff::
-	Allow an external diff helper to be executed. If you set an
-	external diff driver with linkgit:gitattributes[5], you need
-	to use this option with linkgit:git-log[1] and friends.
-
---no-ext-diff::
-	Disallow external diff drivers.
-
---src-prefix=<prefix>::
-	Show the given source prefix instead of "a/".
-
---dst-prefix=<prefix>::
-	Show the given destination prefix instead of "b/".
-
---no-prefix::
-	Do not show any source or destination prefix.
-
-For more detailed explanation on these common options, see also
-link:diffcore.html[diffcore documentation].

Documentation/diffcore.txt

@@ -1,271 +0,0 @@
-Tweaking diff output
-====================
-June 2005
-
-
-Introduction
-------------
-
-The diff commands git-diff-index, git-diff-files, and git-diff-tree
-can be told to manipulate differences they find in
-unconventional ways before showing diff(1) output.  The manipulation
-is collectively called "diffcore transformation".  This short note
-describes what they are and how to use them to produce diff outputs
-that are easier to understand than the conventional kind.
-
-
-The chain of operation
-----------------------
-
-The git-diff-* family works by first comparing two sets of
-files:
-
- - git-diff-index compares contents of a "tree" object and the
-   working directory (when '\--cached' flag is not used) or a
-   "tree" object and the index file (when '\--cached' flag is
-   used);
-
- - git-diff-files compares contents of the index file and the
-   working directory;
-
- - git-diff-tree compares contents of two "tree" objects;
-
-In all of these cases, the commands themselves compare
-corresponding paths in the two sets of files.  The result of
-comparison is passed from these commands to what is internally
-called "diffcore", in a format similar to what is output when
-the -p option is not used.  E.g.
-
-------------------------------------------------
-in-place edit  :100644 100644 bcd1234... 0123456... M file0
-create         :000000 100644 0000000... 1234567... A file4
-delete         :100644 000000 1234567... 0000000... D file5
-unmerged       :000000 000000 0000000... 0000000... U file6
-------------------------------------------------
-
-The diffcore mechanism is fed a list of such comparison results
-(each of which is called "filepair", although at this point each
-of them talks about a single file), and transforms such a list
-into another list.  There are currently 6 such transformations:
-
-- diffcore-pathspec
-- diffcore-break
-- diffcore-rename
-- diffcore-merge-broken
-- diffcore-pickaxe
-- diffcore-order
-
-These are applied in sequence.  The set of filepairs git-diff-\*
-commands find are used as the input to diffcore-pathspec, and
-the output from diffcore-pathspec is used as the input to the
-next transformation.  The final result is then passed to the
-output routine and generates either diff-raw format (see Output
-format sections of the manual for git-diff-\* commands) or
-diff-patch format.
-
-
-diffcore-pathspec: For Ignoring Files Outside Our Consideration
----------------------------------------------------------------
-
-The first transformation in the chain is diffcore-pathspec, and
-is controlled by giving the pathname parameters to the
-git-diff-* commands on the command line.  The pathspec is used
-to limit the world diff operates in.  It removes the filepairs
-outside the specified set of pathnames.  E.g. If the input set
-of filepairs included:
-
-------------------------------------------------
-:100644 100644 bcd1234... 0123456... M junkfile
-------------------------------------------------
-
-but the command invocation was "git-diff-files myfile", then the
-junkfile entry would be removed from the list because only "myfile"
-is under consideration.
-
-Implementation note.  For performance reasons, git-diff-tree
-uses the pathname parameters on the command line to cull set of
-filepairs it feeds the diffcore mechanism itself, and does not
-use diffcore-pathspec, but the end result is the same.
-
-
-diffcore-break: For Splitting Up "Complete Rewrites"
-----------------------------------------------------
-
-The second transformation in the chain is diffcore-break, and is
-controlled by the -B option to the git-diff-* commands.  This is
-used to detect a filepair that represents "complete rewrite" and
-break such filepair into two filepairs that represent delete and
-create.  E.g.  If the input contained this filepair:
-
-------------------------------------------------
-:100644 100644 bcd1234... 0123456... M file0
-------------------------------------------------
-
-and if it detects that the file "file0" is completely rewritten,
-it changes it to:
-
-------------------------------------------------
-:100644 000000 bcd1234... 0000000... D file0
-:000000 100644 0000000... 0123456... A file0
-------------------------------------------------
-
-For the purpose of breaking a filepair, diffcore-break examines
-the extent of changes between the contents of the files before
-and after modification (i.e. the contents that have "bcd1234..."
-and "0123456..." as their SHA1 content ID, in the above
-example).  The amount of deletion of original contents and
-insertion of new material are added together, and if it exceeds
-the "break score", the filepair is broken into two.  The break
-score defaults to 50% of the size of the smaller of the original
-and the result (i.e. if the edit shrinks the file, the size of
-the result is used; if the edit lengthens the file, the size of
-the original is used), and can be customized by giving a number
-after "-B" option (e.g. "-B75" to tell it to use 75%).
-
-
-diffcore-rename: For Detection Renames and Copies
--------------------------------------------------
-
-This transformation is used to detect renames and copies, and is
-controlled by the -M option (to detect renames) and the -C option
-(to detect copies as well) to the git-diff-* commands.  If the
-input contained these filepairs:
-
-------------------------------------------------
-:100644 000000 0123456... 0000000... D fileX
-:000000 100644 0000000... 0123456... A file0
-------------------------------------------------
-
-and the contents of the deleted file fileX is similar enough to
-the contents of the created file file0, then rename detection
-merges these filepairs and creates:
-
-------------------------------------------------
-:100644 100644 0123456... 0123456... R100 fileX file0
-------------------------------------------------
-
-When the "-C" option is used, the original contents of modified files,
-and deleted files (and also unmodified files, if the
-"\--find-copies-harder" option is used) are considered as candidates
-of the source files in rename/copy operation.  If the input were like
-these filepairs, that talk about a modified file fileY and a newly
-created file file0:
-
-------------------------------------------------
-:100644 100644 0123456... 1234567... M fileY
-:000000 100644 0000000... bcd3456... A file0
-------------------------------------------------
-
-the original contents of fileY and the resulting contents of
-file0 are compared, and if they are similar enough, they are
-changed to:
-
-------------------------------------------------
-:100644 100644 0123456... 1234567... M fileY
-:100644 100644 0123456... bcd3456... C100 fileY file0
-------------------------------------------------
-
-In both rename and copy detection, the same "extent of changes"
-algorithm used in diffcore-break is used to determine if two
-files are "similar enough", and can be customized to use
-a similarity score different from the default of 50% by giving a
-number after the "-M" or "-C" option (e.g. "-M8" to tell it to use
-8/10 = 80%).
-
-Note.  When the "-C" option is used with `\--find-copies-harder`
-option, git-diff-\* commands feed unmodified filepairs to
-diffcore mechanism as well as modified ones.  This lets the copy
-detector consider unmodified files as copy source candidates at
-the expense of making it slower.  Without `\--find-copies-harder`,
-git-diff-\* commands can detect copies only if the file that was
-copied happened to have been modified in the same changeset.
-
-
-diffcore-merge-broken: For Putting "Complete Rewrites" Back Together
---------------------------------------------------------------------
-
-This transformation is used to merge filepairs broken by
-diffcore-break, and not transformed into rename/copy by
-diffcore-rename, back into a single modification.  This always
-runs when diffcore-break is used.
-
-For the purpose of merging broken filepairs back, it uses a
-different "extent of changes" computation from the ones used by
-diffcore-break and diffcore-rename.  It counts only the deletion
-from the original, and does not count insertion.  If you removed
-only 10 lines from a 100-line document, even if you added 910
-new lines to make a new 1000-line document, you did not do a
-complete rewrite.  diffcore-break breaks such a case in order to
-help diffcore-rename to consider such filepairs as candidate of
-rename/copy detection, but if filepairs broken that way were not
-matched with other filepairs to create rename/copy, then this
-transformation merges them back into the original
-"modification".
-
-The "extent of changes" parameter can be tweaked from the
-default 80% (that is, unless more than 80% of the original
-material is deleted, the broken pairs are merged back into a
-single modification) by giving a second number to -B option,
-like these:
-
-* -B50/60 (give 50% "break score" to diffcore-break, use 60%
-  for diffcore-merge-broken).
-
-* -B/60 (the same as above, since diffcore-break defaults to 50%).
-
-Note that earlier implementation left a broken pair as a separate
-creation and deletion patches.  This was an unnecessary hack and
-the latest implementation always merges all the broken pairs
-back into modifications, but the resulting patch output is
-formatted differently for easier review in case of such
-a complete rewrite by showing the entire contents of old version
-prefixed with '-', followed by the entire contents of new
-version prefixed with '+'.
-
-
-diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
----------------------------------------------------------------------
-
-This transformation is used to find filepairs that represent
-changes that touch a specified string, and is controlled by the
--S option and the `\--pickaxe-all` option to the git-diff-*
-commands.
-
-When diffcore-pickaxe is in use, it checks if there are
-filepairs whose "original" side has the specified string and
-whose "result" side does not.  Such a filepair represents "the
-string appeared in this changeset".  It also checks for the
-opposite case that loses the specified string.
-
-When `\--pickaxe-all` is not in effect, diffcore-pickaxe leaves
-only such filepairs that touch the specified string in its
-output.  When `\--pickaxe-all` is used, diffcore-pickaxe leaves all
-filepairs intact if there is such a filepair, or makes the
-output empty otherwise.  The latter behaviour is designed to
-make reviewing of the changes in the context of the whole
-changeset easier.
-
-
-diffcore-order: For Sorting the Output Based on Filenames
----------------------------------------------------------
-
-This is used to reorder the filepairs according to the user's
-(or project's) taste, and is controlled by the -O option to the
-git-diff-* commands.
-
-This takes a text file each of whose lines is a shell glob
-pattern.  Filepairs that match a glob pattern on an earlier line
-in the file are output before ones that match a later line, and
-filepairs that do not match any glob pattern are output last.
-
-As an example, a typical orderfile for the core git probably
-would look like this:
-
-------------------------------------------------
-README
-Makefile
-Documentation
-*.h
-*.c
-t
-------------------------------------------------

Documentation/docbook-xsl.css

@@ -1,286 +0,0 @@
-/*
-  CSS stylesheet for XHTML produced by DocBook XSL stylesheets.
-  Tested with XSL stylesheets 1.61.2, 1.67.2
-*/
-
-span.strong {
-  font-weight: bold;
-}
-
-body blockquote {
-  margin-top: .75em;
-  line-height: 1.5;
-  margin-bottom: .75em;
-}
-
-html body {
-  margin: 1em 5% 1em 5%;
-  line-height: 1.2;
-}
-
-body div {
-  margin: 0;
-}
-
-h1, h2, h3, h4, h5, h6,
-div.toc p b,
-div.list-of-figures p b,
-div.list-of-tables p b,
-div.abstract p.title
-{
-  color: #527bbd;
-  font-family: tahoma, verdana, sans-serif;
-}
-
-div.toc p:first-child,
-div.list-of-figures p:first-child,
-div.list-of-tables p:first-child,
-div.example p.title
-{
-  margin-bottom: 0.2em;
-}
-
-body h1 {
-  margin: .0em 0 0 -4%;
-  line-height: 1.3;
-  border-bottom: 2px solid silver;
-}
-
-body h2 {
-  margin: 0.5em 0 0 -4%;
-  line-height: 1.3;
-  border-bottom: 2px solid silver;
-}
-
-body h3 {
-  margin: .8em 0 0 -3%;
-  line-height: 1.3;
-}
-
-body h4 {
-  margin: .8em 0 0 -3%;
-  line-height: 1.3;
-}
-
-body h5 {
-  margin: .8em 0 0 -2%;
-  line-height: 1.3;
-}
-
-body h6 {
-  margin: .8em 0 0 -1%;
-  line-height: 1.3;
-}
-
-body hr {
-  border: none; /* Broken on IE6 */
-}
-div.footnotes hr {
-  border: 1px solid silver;
-}
-
-div.navheader th, div.navheader td, div.navfooter td {
-  font-family: sans-serif;
-  font-size: 0.9em;
-  font-weight: bold;
-  color: #527bbd;
-}
-div.navheader img, div.navfooter img {
-  border-style: none;
-}
-div.navheader a, div.navfooter a {
-  font-weight: normal;
-}
-div.navfooter hr {
-  border: 1px solid silver;
-}
-
-body td {
-  line-height: 1.2
-}
-
-body th {
-  line-height: 1.2;
-}
-
-ol {
-  line-height: 1.2;
-}
-
-ul, body dir, body menu {
-  line-height: 1.2;
-}
-
-html {
-  margin: 0;
-  padding: 0;
-}
-
-body h1, body h2, body h3, body h4, body h5, body h6 {
-  margin-left: 0
-}
-
-body pre {
-  margin: 0.5em 10% 0.5em 1em;
-  line-height: 1.0;
-  color: navy;
-}
-
-tt.literal, code.literal {
-  color: navy;
-}
-
-div.literallayout p {
-  padding: 0em;
-  margin: 0em;
-}
-
-div.literallayout {
-  font-family: monospace;
-#  margin: 0.5em 10% 0.5em 1em;
-  margin: 0em;
-  color: navy;
-  border: 1px solid silver;
-  background: #f4f4f4;
-  padding: 0.5em;
-}
-
-.programlisting, .screen {
-  border: 1px solid silver;
-  background: #f4f4f4;
-  margin: 0.5em 10% 0.5em 0;
-  padding: 0.5em 1em;
-}
-
-div.sidebar {
-  background: #ffffee;
-  margin: 1.0em 10% 0.5em 0;
-  padding: 0.5em 1em;
-  border: 1px solid silver;
-}
-div.sidebar * { padding: 0; }
-div.sidebar div { margin: 0; }
-div.sidebar p.title {
-  font-family: sans-serif;
-  margin-top: 0.5em;
-  margin-bottom: 0.2em;
-}
-
-div.bibliomixed {
-  margin: 0.5em 5% 0.5em 1em;
-}
-
-div.glossary dt {
-  font-weight: bold;
-}
-div.glossary dd p {
-  margin-top: 0.2em;
-}
-
-dl {
-  margin: .8em 0;
-  line-height: 1.2;
-}
-
-dt {
-  margin-top: 0.5em;
-}
-
-dt span.term {
-  font-style: italic;
-}
-
-div.variablelist dd p {
-  margin-top: 0;
-}
-
-div.itemizedlist li, div.orderedlist li {
-  margin-left: -0.8em;
-  margin-top: 0.5em;
-}
-
-ul, ol {
-    list-style-position: outside;
-}
-
-div.sidebar ul, div.sidebar ol {
-    margin-left: 2.8em;
-}
-
-div.itemizedlist p.title,
-div.orderedlist p.title,
-div.variablelist p.title
-{
-  margin-bottom: -0.8em;
-}
-
-div.revhistory table {
-  border-collapse: collapse;
-  border: none;
-}
-div.revhistory th {
-  border: none;
-  color: #527bbd;
-  font-family: tahoma, verdana, sans-serif;
-}
-div.revhistory td {
-  border: 1px solid silver;
-}
-
-/* Keep TOC and index lines close together. */
-div.toc dl, div.toc dt,
-div.list-of-figures dl, div.list-of-figures dt,
-div.list-of-tables dl, div.list-of-tables dt,
-div.indexdiv dl, div.indexdiv dt
-{
-  line-height: normal;
-  margin-top: 0;
-  margin-bottom: 0;
-}
-
-/*
-  Table styling does not work because of overriding attributes in
-  generated HTML.
-*/
-div.table table,
-div.informaltable table
-{
-    margin-left: 0;
-    margin-right: 5%;
-    margin-bottom: 0.8em;
-}
-div.informaltable table
-{
-    margin-top: 0.4em
-}
-div.table thead,
-div.table tfoot,
-div.table tbody,
-div.informaltable thead,
-div.informaltable tfoot,
-div.informaltable tbody
-{
-    /* No effect in IE6. */
-    border-top: 2px solid #527bbd;
-    border-bottom: 2px solid #527bbd;
-}
-div.table thead, div.table tfoot,
-div.informaltable thead, div.informaltable tfoot
-{
-    font-weight: bold;
-}
-
-div.mediaobject img {
-    border: 1px solid silver;
-    margin-bottom: 0.8em;
-}
-div.figure p.title,
-div.table p.title
-{
-  margin-top: 1em;
-  margin-bottom: 0.4em;
-}
-
-@media print {
-  div.navheader, div.navfooter { display: none; }
-}

Documentation/docbook.xsl

@@ -1,5 +0,0 @@
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
-		version='1.0'>
- <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"/>
- <xsl:output method="html" encoding="UTF-8" indent="no" />
-</xsl:stylesheet>

Documentation/everyday.txt

@@ -1,458 +0,0 @@
-Everyday GIT With 20 Commands Or So
-===================================
-
-<<Basic Repository>> commands are needed by people who have a
-repository --- that is everybody, because every working tree of
-git is a repository.
-
-In addition, <<Individual Developer (Standalone)>> commands are
-essential for anybody who makes a commit, even for somebody who
-works alone.
-
-If you work with other people, you will need commands listed in
-the <<Individual Developer (Participant)>> section as well.
-
-People who play the <<Integrator>> role need to learn some more
-commands in addition to the above.
-
-<<Repository Administration>> commands are for system
-administrators who are responsible for the care and feeding
-of git repositories.
-
-
-Basic Repository[[Basic Repository]]
-------------------------------------
-
-Everybody uses these commands to maintain git repositories.
-
-  * linkgit:git-init[1] or linkgit:git-clone[1] to create a
-    new repository.
-
-  * linkgit:git-fsck[1] to check the repository for errors.
-
-  * linkgit:git-gc[1] to do common housekeeping tasks such as
-    repack and prune.
-
-Examples
-~~~~~~~~
-
-Check health and remove cruft.::
-+
-------------
-$ git fsck <1>
-$ git count-objects <2>
-$ git gc <3>
-------------
-+
-<1> running without `\--full` is usually cheap and assures the
-repository health reasonably well.
-<2> check how many loose objects there are and how much
-disk space is wasted by not repacking.
-<3> repacks the local repository and performs other housekeeping tasks. Running
-without `--prune` is a safe operation even while other ones are in progress.
-
-Repack a small project into single pack.::
-+
-------------
-$ git gc <1>
-$ git gc --prune
-------------
-+
-<1> pack all the objects reachable from the refs into one pack,
-then remove the other packs.
-
-
-Individual Developer (Standalone)[[Individual Developer (Standalone)]]
-----------------------------------------------------------------------
-
-A standalone individual developer does not exchange patches with
-other people, and works alone in a single repository, using the
-following commands.
-
-  * linkgit:git-show-branch[1] to see where you are.
-
-  * linkgit:git-log[1] to see what happened.
-
-  * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
-    branches.
-
-  * linkgit:git-add[1] to manage the index file.
-
-  * linkgit:git-diff[1] and linkgit:git-status[1] to see what
-    you are in the middle of doing.
-
-  * linkgit:git-commit[1] to advance the current branch.
-
-  * linkgit:git-reset[1] and linkgit:git-checkout[1] (with
-    pathname parameters) to undo changes.
-
-  * linkgit:git-merge[1] to merge between local branches.
-
-  * linkgit:git-rebase[1] to maintain topic branches.
-
-  * linkgit:git-tag[1] to mark known point.
-
-Examples
-~~~~~~~~
-
-Use a tarball as a starting point for a new repository.::
-+
-------------
-$ tar zxf frotz.tar.gz
-$ cd frotz
-$ git-init
-$ git add . <1>
-$ git commit -m "import of frotz source tree."
-$ git tag v2.43 <2>
-------------
-+
-<1> add everything under the current directory.
-<2> make a lightweight, unannotated tag.
-
-Create a topic branch and develop.::
-+
-------------
-$ git checkout -b alsa-audio <1>
-$ edit/compile/test
-$ git checkout -- curses/ux_audio_oss.c <2>
-$ git add curses/ux_audio_alsa.c <3>
-$ edit/compile/test
-$ git diff HEAD <4>
-$ git commit -a -s <5>
-$ edit/compile/test
-$ git reset --soft HEAD^ <6>
-$ edit/compile/test
-$ git diff ORIG_HEAD <7>
-$ git commit -a -c ORIG_HEAD <8>
-$ git checkout master <9>
-$ git merge alsa-audio <10>
-$ git log --since='3 days ago' <11>
-$ git log v2.43.. curses/ <12>
-------------
-+
-<1> create a new topic branch.
-<2> revert your botched changes in `curses/ux_audio_oss.c`.
-<3> you need to tell git if you added a new file; removal and
-modification will be caught if you do `git commit -a` later.
-<4> to see what changes you are committing.
-<5> commit everything as you have tested, with your sign-off.
-<6> take the last commit back, keeping what is in the working tree.
-<7> look at the changes since the premature commit we took back.
-<8> redo the commit undone in the previous step, using the message
-you originally wrote.
-<9> switch to the master branch.
-<10> merge a topic branch into your master branch.
-<11> review commit logs; other forms to limit output can be
-combined and include `\--max-count=10` (show 10 commits),
-`\--until=2005-12-10`, etc.
-<12> view only the changes that touch what's in `curses/`
-directory, since `v2.43` tag.
-
-
-Individual Developer (Participant)[[Individual Developer (Participant)]]
-------------------------------------------------------------------------
-
-A developer working as a participant in a group project needs to
-learn how to communicate with others, and uses these commands in
-addition to the ones needed by a standalone developer.
-
-  * linkgit:git-clone[1] from the upstream to prime your local
-    repository.
-
-  * linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin"
-    to keep up-to-date with the upstream.
-
-  * linkgit:git-push[1] to shared repository, if you adopt CVS
-    style shared repository workflow.
-
-  * linkgit:git-format-patch[1] to prepare e-mail submission, if
-    you adopt Linux kernel-style public forum workflow.
-
-Examples
-~~~~~~~~
-
-Clone the upstream and work on it.  Feed changes to upstream.::
-+
-------------
-$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
-$ cd my2.6
-$ edit/compile/test; git commit -a -s <1>
-$ git format-patch origin <2>
-$ git pull <3>
-$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
-$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
-$ git reset --hard ORIG_HEAD <6>
-$ git gc --prune <7>
-$ git fetch --tags <8>
-------------
-+
-<1> repeat as needed.
-<2> extract patches from your branch for e-mail submission.
-<3> `git pull` fetches from `origin` by default and merges into the
-current branch.
-<4> immediately after pulling, look at the changes done upstream
-since last time we checked, only in the
-area we are interested in.
-<5> fetch from a specific branch from a specific repository and merge.
-<6> revert the pull.
-<7> garbage collect leftover objects from reverted pull.
-<8> from time to time, obtain official tags from the `origin`
-and store them under `.git/refs/tags/`.
-
-
-Push into another repository.::
-+
-------------
-satellite$ git clone mothership:frotz frotz <1>
-satellite$ cd frotz
-satellite$ git config --get-regexp '^(remote|branch)\.' <2>
-remote.origin.url mothership:frotz
-remote.origin.fetch refs/heads/*:refs/remotes/origin/*
-branch.master.remote origin
-branch.master.merge refs/heads/master
-satellite$ git config remote.origin.push \
-           master:refs/remotes/satellite/master <3>
-satellite$ edit/compile/test/commit
-satellite$ git push origin <4>
-
-mothership$ cd frotz
-mothership$ git checkout master
-mothership$ git merge satellite/master <5>
-------------
-+
-<1> mothership machine has a frotz repository under your home
-directory; clone from it to start a repository on the satellite
-machine.
-<2> clone sets these configuration variables by default.
-It arranges `git pull` to fetch and store the branches of mothership
-machine to local `remotes/origin/*` tracking branches.
-<3> arrange `git push` to push local `master` branch to
-`remotes/satellite/master` branch of the mothership machine.
-<4> push will stash our work away on `remotes/satellite/master`
-tracking branch on the mothership machine.  You could use this as
-a back-up method.
-<5> on mothership machine, merge the work done on the satellite
-machine into the master branch.
-
-Branch off of a specific tag.::
-+
-------------
-$ git checkout -b private2.6.14 v2.6.14 <1>
-$ edit/compile/test; git commit -a
-$ git checkout master
-$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
-  git am -3 -k <2>
-------------
-+
-<1> create a private branch based on a well known (but somewhat behind)
-tag.
-<2> forward port all changes in `private2.6.14` branch to `master` branch
-without a formal "merging".
-
-
-Integrator[[Integrator]]
-------------------------
-
-A fairly central person acting as the integrator in a group
-project receives changes made by others, reviews and integrates
-them and publishes the result for others to use, using these
-commands in addition to the ones needed by participants.
-
-  * linkgit:git-am[1] to apply patches e-mailed in from your
-    contributors.
-
-  * linkgit:git-pull[1] to merge from your trusted lieutenants.
-
-  * linkgit:git-format-patch[1] to prepare and send suggested
-    alternative to contributors.
-
-  * linkgit:git-revert[1] to undo botched commits.
-
-  * linkgit:git-push[1] to publish the bleeding edge.
-
-
-Examples
-~~~~~~~~
-
-My typical GIT day.::
-+
-------------
-$ git status <1>
-$ git show-branch <2>
-$ mailx <3>
-& s 2 3 4 5 ./+to-apply
-& s 7 8 ./+hold-linus
-& q
-$ git checkout -b topic/one master
-$ git am -3 -i -s -u ./+to-apply <4>
-$ compile/test
-$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>
-$ git checkout topic/one && git rebase master <6>
-$ git checkout pu && git reset --hard next <7>
-$ git merge topic/one topic/two && git merge hold/linus <8>
-$ git checkout maint
-$ git cherry-pick master~4 <9>
-$ compile/test
-$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
-$ git fetch ko && git show-branch master maint 'tags/ko-*' <11>
-$ git push ko <12>
-$ git push ko v0.99.9x <13>
-------------
-+
-<1> see what I was in the middle of doing, if any.
-<2> see what topic branches I have and think about how ready
-they are.
-<3> read mails, save ones that are applicable, and save others
-that are not quite ready.
-<4> apply them, interactively, with my sign-offs.
-<5> create topic branch as needed and apply, again with my
-sign-offs.
-<6> rebase internal topic branch that has not been merged to the
-master, nor exposed as a part of a stable branch.
-<7> restart `pu` every time from the next.
-<8> and bundle topic branches still cooking.
-<9> backport a critical fix.
-<10> create a signed tag.
-<11> make sure I did not accidentally rewind master beyond what I
-already pushed out.  `ko` shorthand points at the repository I have
-at kernel.org, and looks like this:
-+
-------------
-$ cat .git/remotes/ko
-URL: kernel.org:/pub/scm/git/git.git
-Pull: master:refs/tags/ko-master
-Pull: next:refs/tags/ko-next
-Pull: maint:refs/tags/ko-maint
-Push: master
-Push: next
-Push: +pu
-Push: maint
-------------
-+
-In the output from `git show-branch`, `master` should have
-everything `ko-master` has, and `next` should have
-everything `ko-next` has.
-
-<12> push out the bleeding edge.
-<13> push the tag out, too.
-
-
-Repository Administration[[Repository Administration]]
-------------------------------------------------------
-
-A repository administrator uses the following tools to set up
-and maintain access to the repository by developers.
-
-  * linkgit:git-daemon[1] to allow anonymous download from
-    repository.
-
-  * linkgit:git-shell[1] can be used as a 'restricted login shell'
-    for shared central repository users.
-
-link:howto/update-hook-example.txt[update hook howto] has a good
-example of managing a shared central repository.
-
-
-Examples
-~~~~~~~~
-We assume the following in /etc/services::
-+
-------------
-$ grep 9418 /etc/services
-git		9418/tcp		# Git Version Control System
-------------
-
-Run git-daemon to serve /pub/scm from inetd.::
-+
-------------
-$ grep git /etc/inetd.conf
-git	stream	tcp	nowait	nobody \
-  /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
-------------
-+
-The actual configuration line should be on one line.
-
-Run git-daemon to serve /pub/scm from xinetd.::
-+
-------------
-$ cat /etc/xinetd.d/git-daemon
-# default: off
-# description: The git server offers access to git repositories
-service git
-{
-        disable = no
-        type            = UNLISTED
-        port            = 9418
-        socket_type     = stream
-        wait            = no
-        user            = nobody
-        server          = /usr/bin/git-daemon
-        server_args     = --inetd --export-all --base-path=/pub/scm
-        log_on_failure  += USERID
-}
-------------
-+
-Check your xinetd(8) documentation and setup, this is from a Fedora system.
-Others might be different.
-
-Give push/pull only access to developers.::
-+
-------------
-$ grep git /etc/passwd <1>
-alice:x:1000:1000::/home/alice:/usr/bin/git-shell
-bob:x:1001:1001::/home/bob:/usr/bin/git-shell
-cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
-david:x:1003:1003::/home/david:/usr/bin/git-shell
-$ grep git /etc/shells <2>
-/usr/bin/git-shell
-------------
-+
-<1> log-in shell is set to /usr/bin/git-shell, which does not
-allow anything but `git push` and `git pull`.  The users should
-get an ssh access to the machine.
-<2> in many distributions /etc/shells needs to list what is used
-as the login shell.
-
-CVS-style shared repository.::
-+
-------------
-$ grep git /etc/group <1>
-git:x:9418:alice,bob,cindy,david
-$ cd /home/devo.git
-$ ls -l <2>
-  lrwxrwxrwx   1 david git    17 Dec  4 22:40 HEAD -> refs/heads/master
-  drwxrwsr-x   2 david git  4096 Dec  4 22:40 branches
-  -rw-rw-r--   1 david git    84 Dec  4 22:40 config
-  -rw-rw-r--   1 david git    58 Dec  4 22:40 description
-  drwxrwsr-x   2 david git  4096 Dec  4 22:40 hooks
-  -rw-rw-r--   1 david git 37504 Dec  4 22:40 index
-  drwxrwsr-x   2 david git  4096 Dec  4 22:40 info
-  drwxrwsr-x   4 david git  4096 Dec  4 22:40 objects
-  drwxrwsr-x   4 david git  4096 Nov  7 14:58 refs
-  drwxrwsr-x   2 david git  4096 Dec  4 22:40 remotes
-$ ls -l hooks/update <3>
-  -r-xr-xr-x   1 david git  3536 Dec  4 22:40 update
-$ cat info/allowed-users <4>
-refs/heads/master	alice\|cindy
-refs/heads/doc-update	bob
-refs/tags/v[0-9]*	david
-------------
-+
-<1> place the developers into the same git group.
-<2> and make the shared repository writable by the group.
-<3> use update-hook example by Carl from Documentation/howto/
-for branch policy control.
-<4> alice and cindy can push into master, only bob can push into doc-update.
-david is the release manager and is the only person who can
-create and push version tags.
-
-HTTP server to support dumb protocol transfer.::
-+
-------------
-dev$ git update-server-info <1>
-dev$ ftp user@isp.example.com <2>
-ftp> cp -r .git /home/user/myproject.git
-------------
-+
-<1> make sure your info/refs and objects/info/packs are up-to-date
-<2> upload to public HTTP server hosted by your ISP.

Documentation/fetch-options.txt

@@ -1,58 +0,0 @@
--q, \--quiet::
-	Pass --quiet to git-fetch-pack and silence any other internally
-	used programs.
-
--v, \--verbose::
-	Be verbose.
-
--a, \--append::
-	Append ref names and object names of fetched refs to the
-	existing contents of `.git/FETCH_HEAD`.  Without this
-	option old data in `.git/FETCH_HEAD` will be overwritten.
-
-\--upload-pack <upload-pack>::
-	When given, and the repository to fetch from is handled
-	by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
-	the command to specify non-default path for the command
-	run on the other end.
-
--f, \--force::
-	When `git-fetch` is used with `<rbranch>:<lbranch>`
-	refspec, it refuses to update the local branch
-	`<lbranch>` unless the remote branch `<rbranch>` it
-	fetches is a descendant of `<lbranch>`.  This option
-	overrides that check.
-
-ifdef::git-pull[]
-\--no-tags::
-endif::git-pull[]
-ifndef::git-pull[]
--n, \--no-tags::
-endif::git-pull[]
-	By default, tags that point at objects that are downloaded
-	from the remote repository are fetched and stored locally.
-	This option disables this automatic tag following.
-
--t, \--tags::
-	Most of the tags are fetched automatically as branch
-	heads are downloaded, but tags that do not point at
-	objects reachable from the branch heads that are being
-	tracked will not be fetched by this mechanism.  This
-	flag lets all tags and their associated objects be
-	downloaded.
-
--k, \--keep::
-	Keep downloaded pack.
-
--u, \--update-head-ok::
-	By default `git-fetch` refuses to update the head which
-	corresponds to the current branch.  This flag disables the
-	check.  This is purely for the internal use for `git-pull`
-	to communicate with `git-fetch`, and unless you are
-	implementing your own Porcelain you are not supposed to
-	use it.
-
-\--depth=<depth>::
-	Deepen the history of a 'shallow' repository created by
-	`git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
-	by the specified number of commits.

Documentation/fix-texi.perl

@@ -1,15 +0,0 @@
-#!/usr/bin/perl -w
-
-while (<>) {
-	if (/^\@setfilename/) {
-		$_ = "\@setfilename git.info\n";
-	} elsif (/^\@direntry/) {
-		print '@dircategory Development
-@direntry
-* Git: (git).           A fast distributed revision control system
-@end direntry
-';	}
-	unless (/^\@direntry/../^\@end direntry/) {
-		print;
-	}
-}

Documentation/git-add.txt

@@ -1,251 +0,0 @@
-git-add(1)
-==========
-
-NAME
-----
-git-add - Add file contents to the index
-
-SYNOPSIS
---------
-[verse]
-'git-add' [-n] [-v] [-f] [--interactive | -i] [--patch | -p] [-u] [--refresh]
-          [--] <filepattern>...
-
-DESCRIPTION
------------
-This command adds the current content of new or modified files to the
-index, thus staging that content for inclusion in the next commit.
-
-The "index" holds a snapshot of the content of the working tree, and it
-is this snapshot that is taken as the contents of the next commit.  Thus
-after making any changes to the working directory, and before running
-the commit command, you must use the 'add' command to add any new or
-modified files to the index.
-
-This command can be performed multiple times before a commit.  It only
-adds the content of the specified file(s) at the time the add command is
-run; if you want subsequent changes included in the next commit, then
-you must run 'git add' again to add the new content to the index.
-
-The 'git status' command can be used to obtain a summary of which
-files have changes that are staged for the next commit.
-
-The 'git add' command will not add ignored files by default.  If any
-ignored files were explicitly specified on the command line, 'git add'
-will fail with a list of ignored files.  Ignored files reached by
-directory recursion or filename globbing performed by Git (quote your
-globs before the shell) will be silently ignored.  The 'add' command can
-be used to add ignored files with the `-f` (force) option.
-
-Please see linkgit:git-commit[1] for alternative ways to add content to a
-commit.
-
-
-OPTIONS
--------
-<filepattern>...::
-	Files to add content from.  Fileglobs (e.g. `*.c`) can
-	be given to add all matching files.  Also a
-	leading directory name (e.g. `dir` to add `dir/file1`
-	and `dir/file2`) can be given to add all files in the
-	directory, recursively.
-
--n, \--dry-run::
-        Don't actually add the file(s), just show if they exist.
-
--v, \--verbose::
-        Be verbose.
-
--f::
-	Allow adding otherwise ignored files.
-
--i, \--interactive::
-	Add modified contents in the working tree interactively to
-	the index. Optional path arguments may be supplied to limit
-	operation to a subset of the working tree. See ``Interactive
-	mode'' for details.
-
--p, \--patch::
-	Similar to Interactive mode but the initial command loop is
-	bypassed and the 'patch' subcommand is invoked using each of
-	the specified filepatterns before exiting.
-
--u::
-	Update only files that git already knows about. This is similar
-	to what "git commit -a" does in preparation for making a commit,
-	except that the update is limited to paths specified on the
-	command line. If no paths are specified, all tracked files are
-	updated.
-
-\--refresh::
-	Don't add the file(s), but only refresh their stat()
-	information in the index.
-
-\--::
-	This option can be used to separate command-line options from
-	the list of files, (useful when filenames might be mistaken
-	for command-line options).
-
-
-Configuration
--------------
-
-The optional configuration variable 'core.excludesfile' indicates a path to a
-file containing patterns of file names to exclude from git-add, similar to
-$GIT_DIR/info/exclude.  Patterns in the exclude file are used in addition to
-those in info/exclude.  See link:repository-layout.html[repository layout].
-
-
-EXAMPLES
---------
-git-add Documentation/\\*.txt::
-
-	Adds content from all `\*.txt` files under `Documentation`
-	directory and its subdirectories.
-+
-Note that the asterisk `\*` is quoted from the shell in this
-example; this lets the command to include the files from
-subdirectories of `Documentation/` directory.
-
-git-add git-*.sh::
-
-	Considers adding content from all git-*.sh scripts.
-	Because this example lets shell expand the asterisk
-	(i.e. you are listing the files explicitly), it does not
-	consider `subdir/git-foo.sh`.
-
-Interactive mode
-----------------
-When the command enters the interactive mode, it shows the
-output of the 'status' subcommand, and then goes into its
-interactive command loop.
-
-The command loop shows the list of subcommands available, and
-gives a prompt "What now> ".  In general, when the prompt ends
-with a single '>', you can pick only one of the choices given
-and type return, like this:
-
-------------
-    *** Commands ***
-      1: status       2: update       3: revert       4: add untracked
-      5: patch        6: diff         7: quit         8: help
-    What now> 1
-------------
-
-You also could say "s" or "sta" or "status" above as long as the
-choice is unique.
-
-The main command loop has 6 subcommands (plus help and quit).
-
-status::
-
-   This shows the change between HEAD and index (i.e. what will be
-   committed if you say "git commit"), and between index and
-   working tree files (i.e. what you could stage further before
-   "git commit" using "git-add") for each path.  A sample output
-   looks like this:
-+
-------------
-              staged     unstaged path
-     1:       binary      nothing foo.png
-     2:     +403/-35        +1/-1 git-add--interactive.perl
-------------
-+
-It shows that foo.png has differences from HEAD (but that is
-binary so line count cannot be shown) and there is no
-difference between indexed copy and the working tree
-version (if the working tree version were also different,
-'binary' would have been shown in place of 'nothing').  The
-other file, git-add--interactive.perl, has 403 lines added
-and 35 lines deleted if you commit what is in the index, but
-working tree file has further modifications (one addition and
-one deletion).
-
-update::
-
-   This shows the status information and gives prompt
-   "Update>>".  When the prompt ends with double '>>', you can
-   make more than one selection, concatenated with whitespace or
-   comma.  Also you can say ranges.  E.g. "2-5 7,9" to choose
-   2,3,4,5,7,9 from the list.  You can say '*' to choose
-   everything.
-+
-What you chose are then highlighted with '*',
-like this:
-+
-------------
-           staged     unstaged path
-  1:       binary      nothing foo.png
-* 2:     +403/-35        +1/-1 git-add--interactive.perl
-------------
-+
-To remove selection, prefix the input with `-`
-like this:
-+
-------------
-Update>> -2
-------------
-+
-After making the selection, answer with an empty line to stage the
-contents of working tree files for selected paths in the index.
-
-revert::
-
-  This has a very similar UI to 'update', and the staged
-  information for selected paths are reverted to that of the
-  HEAD version.  Reverting new paths makes them untracked.
-
-add untracked::
-
-  This has a very similar UI to 'update' and
-  'revert', and lets you add untracked paths to the index.
-
-patch::
-
-  This lets you choose one path out of 'status' like selection.
-  After choosing the path, it presents diff between the index
-  and the working tree file and asks you if you want to stage
-  the change of each hunk.  You can say:
-
-       y - add the change from that hunk to index
-       n - do not add the change from that hunk to index
-       a - add the change from that hunk and all the rest to index
-       d - do not the change from that hunk nor any of the rest to index
-       j - do not decide on this hunk now, and view the next
-           undecided hunk
-       J - do not decide on this hunk now, and view the next hunk
-       k - do not decide on this hunk now, and view the previous
-           undecided hunk
-       K - do not decide on this hunk now, and view the previous hunk
-       s - split the current hunk into smaller hunks
-       ? - print help
-+
-After deciding the fate for all hunks, if there is any hunk
-that was chosen, the index is updated with the selected hunks.
-
-diff::
-
-  This lets you review what will be committed (i.e. between
-  HEAD and index).
-
-
-See Also
---------
-linkgit:git-status[1]
-linkgit:git-rm[1]
-linkgit:git-reset[1]
-linkgit:git-mv[1]
-linkgit:git-commit[1]
-linkgit:git-update-index[1]
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-am.txt

@@ -1,160 +0,0 @@
-git-am(1)
-=========
-
-NAME
-----
-git-am - Apply a series of patches from a mailbox
-
-
-SYNOPSIS
---------
-[verse]
-'git-am' [--signoff] [--dotest=<dir>] [--keep] [--utf8 | --no-utf8]
-         [--3way] [--interactive] [--binary]
-         [--whitespace=<option>] [-C<n>] [-p<n>]
-         <mbox>|<Maildir>...
-'git-am' [--skip | --resolved]
-
-DESCRIPTION
------------
-Splits mail messages in a mailbox into commit log message,
-authorship information and patches, and applies them to the
-current branch.
-
-OPTIONS
--------
-<mbox>|<Maildir>...::
-	The list of mailbox files to read patches from. If you do not
-	supply this argument, reads from the standard input. If you supply
-	directories, they'll be treated as Maildirs.
-
--s, --signoff::
-	Add `Signed-off-by:` line to the commit message, using
-	the committer identity of yourself.
-
--d=<dir>, --dotest=<dir>::
-	Instead of `.dotest` directory, use <dir> as a working
-	area to store extracted patches.
-
--k, --keep::
-	Pass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
-
--u, --utf8::
-	Pass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
-	The proposed commit log message taken from the e-mail
-	is re-coded into UTF-8 encoding (configuration variable
-	`i18n.commitencoding` can be used to specify project's
-	preferred encoding if it is not UTF-8).
-+
-This was optional in prior versions of git, but now it is the
-default.   You could use `--no-utf8` to override this.
-
---no-utf8::
-	Pass `-n` flag to `git-mailinfo` (see
-	linkgit:git-mailinfo[1]).
-
--3, --3way::
-	When the patch does not apply cleanly, fall back on
-	3-way merge, if the patch records the identity of blobs
-	it is supposed to apply to, and we have those blobs
-	available locally.
-
--b, --binary::
-	Pass `--allow-binary-replacement` flag to `git-apply`
-	(see linkgit:git-apply[1]).
-
---whitespace=<option>::
-	This flag is passed to the `git-apply` (see linkgit:git-apply[1])
-	program that applies
-	the patch.
-
--C<n>, -p<n>::
-	These flags are passed to the `git-apply` (see linkgit:git-apply[1])
-	program that applies
-	the patch.
-
--i, --interactive::
-	Run interactively.
-
---skip::
-	Skip the current patch.  This is only meaningful when
-	restarting an aborted patch.
-
--r, --resolved::
-	After a patch failure (e.g. attempting to apply
-	conflicting patch), the user has applied it by hand and
-	the index file stores the result of the application.
-	Make a commit using the authorship and commit log
-	extracted from the e-mail message and the current index
-	file, and continue.
-
---resolvemsg=<msg>::
-	When a patch failure occurs, <msg> will be printed
-	to the screen before exiting.  This overrides the
-	standard message informing you to use `--resolved`
-	or `--skip` to handle the failure.  This is solely
-	for internal use between `git-rebase` and `git-am`.
-
-DISCUSSION
-----------
-
-The commit author name is taken from the "From: " line of the
-message, and commit author time is taken from the "Date: " line
-of the message.  The "Subject: " line is used as the title of
-the commit, after stripping common prefix "[PATCH <anything>]".
-It is supposed to describe what the commit is about concisely as
-a one line text.
-
-The body of the message (iow, after a blank line that terminates
-RFC2822 headers) can begin with "Subject: " and "From: " lines
-that are different from those of the mail header, to override
-the values of these fields.
-
-The commit message is formed by the title taken from the
-"Subject: ", a blank line and the body of the message up to
-where the patch begins.  Excess whitespaces at the end of the
-lines are automatically stripped.
-
-The patch is expected to be inline, directly following the
-message.  Any line that is of form:
-
-* three-dashes and end-of-line, or
-* a line that begins with "diff -", or
-* a line that begins with "Index: "
-
-is taken as the beginning of a patch, and the commit log message
-is terminated before the first occurrence of such a line.
-
-When initially invoking it, you give it names of the mailboxes
-to crunch.  Upon seeing the first patch that does not apply, it
-aborts in the middle,.  You can recover from this in one of two ways:
-
-. skip the current patch by re-running the command with '--skip'
-  option.
-
-. hand resolve the conflict in the working directory, and update
-  the index file to bring it in a state that the patch should
-  have produced.  Then run the command with '--resolved' option.
-
-The command refuses to process new mailboxes while `.dotest`
-directory exists, so if you decide to start over from scratch,
-run `rm -f .dotest` before running the command with mailbox
-names.
-
-
-SEE ALSO
---------
-linkgit:git-apply[1].
-
-
-Author
-------
-Written by Junio C Hamano <junkio@cox.net>
-
-Documentation
---------------
-Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-annotate.txt

@@ -1,31 +0,0 @@
-git-annotate(1)
-===============
-
-NAME
-----
-git-annotate - Annotate file lines with commit info
-
-SYNOPSIS
---------
-git-annotate [options] file [revision]
-
-DESCRIPTION
------------
-Annotates each line in the given file with information from the commit
-which introduced the line. Optionally annotate from a given revision.
-
-OPTIONS
--------
-include::blame-options.txt[]
-
-SEE ALSO
---------
-linkgit:git-blame[1]
-
-AUTHOR
-------
-Written by Ryan Anderson <ryan@michonline.com>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-apply.txt

@@ -1,209 +0,0 @@
-git-apply(1)
-============
-
-NAME
-----
-git-apply - Apply a patch on a git index file and a working tree
-
-
-SYNOPSIS
---------
-[verse]
-'git-apply' [--stat] [--numstat] [--summary] [--check] [--index]
-	  [--apply] [--no-add] [--build-fake-ancestor <file>] [-R | --reverse]
-	  [--allow-binary-replacement | --binary] [--reject] [-z]
-	  [-pNUM] [-CNUM] [--inaccurate-eof] [--cached]
-	  [--whitespace=<nowarn|warn|fix|error|error-all>]
-	  [--exclude=PATH] [--verbose] [<patch>...]
-
-DESCRIPTION
------------
-Reads supplied diff output and applies it on a git index file
-and a work tree.
-
-OPTIONS
--------
-<patch>...::
-	The files to read patch from.  '-' can be used to read
-	from the standard input.
-
---stat::
-	Instead of applying the patch, output diffstat for the
-	input.  Turns off "apply".
-
---numstat::
-	Similar to \--stat, but shows number of added and
-	deleted lines in decimal notation and pathname without
-	abbreviation, to make it more machine friendly.  For
-	binary files, outputs two `-` instead of saying
-	`0 0`.  Turns off "apply".
-
---summary::
-	Instead of applying the patch, output a condensed
-	summary of information obtained from git diff extended
-	headers, such as creations, renames and mode changes.
-	Turns off "apply".
-
---check::
-	Instead of applying the patch, see if the patch is
-	applicable to the current work tree and/or the index
-	file and detects errors.  Turns off "apply".
-
---index::
-	When --check is in effect, or when applying the patch
-	(which is the default when none of the options that
-	disables it is in effect), make sure the patch is
-	applicable to what the current index file records.  If
-	the file to be patched in the work tree is not
-	up-to-date, it is flagged as an error.  This flag also
-	causes the index file to be updated.
-
---cached::
-	Apply a patch without touching the working tree. Instead, take the
-	cached data, apply the patch, and store the result in the index,
-	without using the working tree. This implies '--index'.
-
---build-fake-ancestor <file>::
-	Newer git-diff output has embedded 'index information'
-	for each blob to help identify the original version that
-	the patch applies to.  When this flag is given, and if
-	the original versions of the blobs is available locally,
-	builds a temporary index containing those blobs.
-+
-When a pure mode change is encountered (which has no index information),
-the information is read from the current index instead.
-
--R, --reverse::
-	Apply the patch in reverse.
-
---reject::
-	For atomicity, linkgit:git-apply[1] by default fails the whole patch and
-	does not touch the working tree when some of the hunks
-	do not apply.  This option makes it apply
-	the parts of the patch that are applicable, and leave the
-	rejected hunks in corresponding *.rej files.
-
--z::
-	When showing the index information, do not munge paths,
-	but use NUL terminated machine readable format.  Without
-	this flag, the pathnames output will have TAB, LF, and
-	backslash characters replaced with `\t`, `\n`, and `\\`,
-	respectively.
-
--p<n>::
-	Remove <n> leading slashes from traditional diff paths. The
-	default is 1.
-
--C<n>::
-	Ensure at least <n> lines of surrounding context match before
-	and after each change.  When fewer lines of surrounding
-	context exist they all must match.  By default no context is
-	ever ignored.
-
---unidiff-zero::
-	By default, linkgit:git-apply[1] expects that the patch being
-	applied is a unified diff with at least one line of context.
-	This provides good safety measures, but breaks down when
-	applying a diff generated with --unified=0. To bypass these
-	checks use '--unidiff-zero'.
-+
-Note, for the reasons stated above usage of context-free patches are
-discouraged.
-
---apply::
-	If you use any of the options marked "Turns off
-	'apply'" above, linkgit:git-apply[1] reads and outputs the
-	information you asked without actually applying the
-	patch.  Give this flag after those flags to also apply
-	the patch.
-
---no-add::
-	When applying a patch, ignore additions made by the
-	patch.  This can be used to extract the common part between
-	two files by first running `diff` on them and applying
-	the result with this option, which would apply the
-	deletion part but not addition part.
-
---allow-binary-replacement, --binary::
-	Historically we did not allow binary patch applied
-	without an explicit permission from the user, and this
-	flag was the way to do so.  Currently we always allow binary
-	patch application, so this is a no-op.
-
---exclude=<path-pattern>::
-	Don't apply changes to files matching the given path pattern. This can
-	be useful when importing patchsets, where you want to exclude certain
-	files or directories.
-
---whitespace=<action>::
-	When applying a patch, detect a new or modified line that has
-	whitespace errors.  What are considered whitespace errors is
-	controlled by `core.whitespace` configuration.  By default,
-	trailing whitespaces (including lines that solely consist of
-	whitespaces) and a space character that is immediately followed
-	by a tab character inside the initial indent of the line are
-	considered whitespace errors.
-+
-By default, the command outputs warning messages but applies the patch.
-When linkgit:git-apply[1] is used for statistics and not applying a
-patch, it defaults to `nowarn`.
-+
-You can use different `<action>` to control this
-behavior:
-+
-* `nowarn` turns off the trailing whitespace warning.
-* `warn` outputs warnings for a few such errors, but applies the
-  patch as-is (default).
-* `fix` outputs warnings for a few such errors, and applies the
-  patch after fixing them (`strip` is a synonym --- the tool
-  used to consider only trailing whitespaces as errors, and the
-  fix involved 'stripping' them, but modern gits do more).
-* `error` outputs warnings for a few such errors, and refuses
-  to apply the patch.
-* `error-all` is similar to `error` but shows all errors.
-
---inaccurate-eof::
-	Under certain circumstances, some versions of diff do not correctly
-	detect a missing new-line at the end of the file. As a result, patches
-	created by such diff programs do not record incomplete lines
-	correctly. This option adds support for applying such patches by
-	working around this bug.
-
--v, --verbose::
-	Report progress to stderr. By default, only a message about the
-	current patch being applied will be printed. This option will cause
-	additional information to be reported.
-
-Configuration
--------------
-
-apply.whitespace::
-	When no `--whitespace` flag is given from the command
-	line, this configuration item is used as the default.
-
-Submodules
-----------
-If the patch contains any changes to submodules then linkgit:git-apply[1]
-treats these changes as follows.
-
-If --index is specified (explicitly or implicitly), then the submodule
-commits must match the index exactly for the patch to apply.  If any
-of the submodules are checked-out, then these check-outs are completely
-ignored, i.e., they are not required to be up-to-date or clean and they
-are not updated.
-
-If --index is not specified, then the submodule commits in the patch
-are ignored and only the absence of presence of the corresponding
-subdirectory is checked and (if possible) updated.
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-archimport.txt

@@ -1,120 +0,0 @@
-git-archimport(1)
-=================
-
-NAME
-----
-git-archimport - Import an Arch repository into git
-
-
-SYNOPSIS
---------
-[verse]
-'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
-               <archive/branch>[:<git-branch>] ...
-
-DESCRIPTION
------------
-Imports a project from one or more Arch repositories. It will follow branches
-and repositories within the namespaces defined by the <archive/branch>
-parameters supplied. If it cannot find the remote branch a merge comes from
-it will just import it as a regular commit. If it can find it, it will mark it
-as a merge whenever possible (see discussion below).
-
-The script expects you to provide the key roots where it can start the import
-from an 'initial import' or 'tag' type of Arch commit. It will follow and
-import new branches within the provided roots.
-
-It expects to be dealing with one project only. If it sees
-branches that have different roots, it will refuse to run. In that case,
-edit your <archive/branch> parameters to define clearly the scope of the
-import.
-
-`git-archimport` uses `tla` extensively in the background to access the
-Arch repository.
-Make sure you have a recent version of `tla` available in the path. `tla` must
-know about the repositories you pass to `git-archimport`.
-
-For the initial import `git-archimport` expects to find itself in an empty
-directory. To follow the development of a project that uses Arch, rerun
-`git-archimport` with the same parameters as the initial import to perform
-incremental imports.
-
-While git-archimport will try to create sensible branch names for the
-archives that it imports, it is also possible to specify git branch names
-manually.  To do so, write a git branch name after each <archive/branch>
-parameter, separated by a colon.  This way, you can shorten the Arch
-branch names and convert Arch jargon to git jargon, for example mapping a
-"PROJECT--devo--VERSION" branch to "master".
-
-Associating multiple Arch branches to one git branch is possible; the
-result will make the most sense only if no commits are made to the first
-branch, after the second branch is created.  Still, this is useful to
-convert Arch repositories that had been rotated periodically.
-
-
-MERGES
-------
-Patch merge data from Arch is used to mark merges in git as well. git
-does not care much about tracking patches, and only considers a merge when a
-branch incorporates all the commits since the point they forked. The end result
-is that git will have a good idea of how far branches have diverged. So the
-import process does lose some patch-trading metadata.
-
-Fortunately, when you try and merge branches imported from Arch,
-git will find a good merge base, and it has a good chance of identifying
-patches that have been traded out-of-sequence between the branches.
-
-OPTIONS
--------
-
--h::
-	Display usage.
-
--v::
-	Verbose output.
-
--T::
-	Many tags. Will create a tag for every commit, reflecting the commit
-	name in the Arch repository.
-
--f::
-	Use the fast patchset import strategy.  This can be significantly
-	faster for large trees, but cannot handle directory renames or
-	permissions changes.  The default strategy is slow and safe.
-
--o::
-	Use this for compatibility with old-style branch names used by
-	earlier versions of git-archimport.  Old-style branch names
-	were category--branch, whereas new-style branch names are
-	archive,category--branch--version.  In both cases, names given
-	on the command-line will override the automatically-generated
-	ones.
-
--D <depth>::
-	Follow merge ancestry and attempt to import trees that have been
-	merged from.  Specify a depth greater than 1 if patch logs have been
-	pruned.
-
--a::
-	Attempt to auto-register archives at http://mirrors.sourcecontrol.net
-	This is particularly useful with the -D option.
-
--t <tmpdir>::
-	Override the default tempdir.
-
-
-<archive/branch>::
-	Archive/branch identifier in a format that `tla log` understands.
-
-
-Author
-------
-Written by Martin Langhoff <martin@catalyst.net.nz>.
-
-Documentation
---------------
-Documentation by Junio C Hamano, Martin Langhoff and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-archive.txt

@@ -1,121 +0,0 @@
-git-archive(1)
-==============
-
-NAME
-----
-git-archive - Create an archive of files from a named tree
-
-
-SYNOPSIS
---------
-[verse]
-'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
-	      [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
-	      [path...]
-
-DESCRIPTION
------------
-Creates an archive of the specified format containing the tree
-structure for the named tree, and writes it out to the standard
-output.  If <prefix> is specified it is
-prepended to the filenames in the archive.
-
-'git-archive' behaves differently when given a tree ID versus when
-given a commit ID or tag ID.  In the first case the current time is
-used as modification time of each file in the archive.  In the latter
-case the commit time as recorded in the referenced commit object is
-used instead.  Additionally the commit ID is stored in a global
-extended pax header if the tar format is used; it can be extracted
-using 'git-get-tar-commit-id'. In ZIP files it is stored as a file
-comment.
-
-OPTIONS
--------
-
---format=<fmt>::
-	Format of the resulting archive: 'tar' or 'zip'.  The default
-	is 'tar'.
-
---list, -l::
-	Show all available formats.
-
---verbose, -v::
-	Report progress to stderr.
-
---prefix=<prefix>/::
-	Prepend <prefix>/ to each filename in the archive.
-
-<extra>::
-	This can be any options that the archiver backend understand.
-	See next section.
-
---remote=<repo>::
-	Instead of making a tar archive from local repository,
-	retrieve a tar archive from a remote repository.
-
---exec=<git-upload-archive>::
-	Used with --remote to specify the path to the
-	git-upload-archive executable on the remote side.
-
-<tree-ish>::
-	The tree or commit to produce an archive for.
-
-path::
-	If one or more paths are specified, include only these in the
-	archive, otherwise include all files and subdirectories.
-
-BACKEND EXTRA OPTIONS
----------------------
-
-zip
-~~~
--0::
-	Store the files instead of deflating them.
--9::
-	Highest and slowest compression level.  You can specify any
-	number from 1 to 9 to adjust compression speed and ratio.
-
-
-CONFIGURATION
--------------
-
-tar.umask::
-	This variable can be used to restrict the permission bits of
-	tar archive entries.  The default is 0002, which turns off the
-	world write bit.  The special value "user" indicates that the
-	archiving user's umask will be used instead.  See umask(2) for
-	details.
-
-EXAMPLES
---------
-git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
-
-	Create a tar archive that contains the contents of the
-	latest commit on the current branch, and extracts it in
-	`/var/tmp/junk` directory.
-
-git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz::
-
-	Create a compressed tarball for v1.4.0 release.
-
-git archive --format=tar --prefix=git-1.4.0/ v1.4.0{caret}\{tree\} | gzip >git-1.4.0.tar.gz::
-
-	Create a compressed tarball for v1.4.0 release, but without a
-	global extended pax header.
-
-git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip::
-
-	Put everything in the current head's Documentation/ directory
-	into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
-
-Author
-------
-Written by Franck Bui-Huu and Rene Scharfe.
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-bisect.txt

@@ -1,230 +0,0 @@
-git-bisect(1)
-=============
-
-NAME
-----
-git-bisect - Find the change that introduced a bug by binary search
-
-
-SYNOPSIS
---------
-'git bisect' <subcommand> <options>
-
-DESCRIPTION
------------
-The command takes various subcommands, and different options depending
-on the subcommand:
-
- git bisect start [<bad> [<good>...]] [--] [<paths>...]
- git bisect bad [<rev>]
- git bisect good [<rev>...]
- git bisect skip [<rev>...]
- git bisect reset [<branch>]
- git bisect visualize
- git bisect replay <logfile>
- git bisect log
- git bisect run <cmd>...
-
-This command uses 'git-rev-list --bisect' option to help drive the
-binary search process to find which change introduced a bug, given an
-old "good" commit object name and a later "bad" commit object name.
-
-Basic bisect commands: start, bad, good
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The way you use it is:
-
-------------------------------------------------
-$ git bisect start
-$ git bisect bad                 # Current version is bad
-$ git bisect good v2.6.13-rc2    # v2.6.13-rc2 was the last version
-                                 # tested that was good
-------------------------------------------------
-
-When you give at least one bad and one good versions, it will bisect
-the revision tree and say something like:
-
-------------------------------------------------
-Bisecting: 675 revisions left to test after this
-------------------------------------------------
-
-and check out the state in the middle. Now, compile that kernel, and
-boot it. Now, let's say that this booted kernel works fine, then just
-do
-
-------------------------------------------------
-$ git bisect good			# this one is good
-------------------------------------------------
-
-which will now say
-
-------------------------------------------------
-Bisecting: 337 revisions left to test after this
-------------------------------------------------
-
-and you continue along, compiling that one, testing it, and depending
-on whether it is good or bad, you say "git bisect good" or "git bisect
-bad", and ask for the next bisection.
-
-Until you have no more left, and you'll have been left with the first
-bad kernel rev in "refs/bisect/bad".
-
-Bisect reset
-~~~~~~~~~~~~
-
-Oh, and then after you want to reset to the original head, do a
-
-------------------------------------------------
-$ git bisect reset
-------------------------------------------------
-
-to get back to the master branch, instead of being in one of the
-bisection branches ("git bisect start" will do that for you too,
-actually: it will reset the bisection state, and before it does that
-it checks that you're not using some old bisection branch).
-
-Bisect visualize
-~~~~~~~~~~~~~~~~
-
-During the bisection process, you can say
-
-------------
-$ git bisect visualize
-------------
-
-to see the currently remaining suspects in `gitk`.  `visualize` is a bit
-too long to type and `view` is provided as a synonym.
-
-If `DISPLAY` environment variable is not set, `git log` is used
-instead.  You can even give command line options such as `-p` and
-`--stat`.
-
-------------
-$ git bisect view --stat
-------------
-
-Bisect log and bisect replay
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The good/bad input is logged, and
-
-------------
-$ git bisect log
-------------
-
-shows what you have done so far. You can truncate its output somewhere
-and save it in a file, and run
-
-------------
-$ git bisect replay that-file
-------------
-
-if you find later you made a mistake telling good/bad about a
-revision.
-
-Avoiding to test a commit
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If in a middle of bisect session, you know what the bisect suggested
-to try next is not a good one to test (e.g. the change the commit
-introduces is known not to work in your environment and you know it
-does not have anything to do with the bug you are chasing), you may
-want to find a near-by commit and try that instead.
-
-It goes something like this:
-
-------------
-$ git bisect good/bad			# previous round was good/bad.
-Bisecting: 337 revisions left to test after this
-$ git bisect visualize			# oops, that is uninteresting.
-$ git reset --hard HEAD~3		# try 3 revs before what
-					# was suggested
-------------
-
-Then compile and test the one you chose to try. After that, tell
-bisect what the result was as usual.
-
-Bisect skip
-~~~~~~~~~~~~
-
-Instead of choosing by yourself a nearby commit, you may just want git
-to do it for you using:
-
-------------
-$ git bisect skip                 # Current version cannot be tested
-------------
-
-But computing the commit to test may be slower afterwards and git may
-eventually not be able to tell the first bad among a bad and one or
-more "skip"ped commits.
-
-Cutting down bisection by giving more parameters to bisect start
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You can further cut down the number of trials if you know what part of
-the tree is involved in the problem you are tracking down, by giving
-paths parameters when you say `bisect start`, like this:
-
-------------
-$ git bisect start -- arch/i386 include/asm-i386
-------------
-
-If you know beforehand more than one good commits, you can narrow the
-bisect space down without doing the whole tree checkout every time you
-give good commits. You give the bad revision immediately after `start`
-and then you give all the good revisions you have:
-
-------------
-$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
-                   # v2.6.20-rc6 is bad
-                   # v2.6.20-rc4 and v2.6.20-rc1 are good
-------------
-
-Bisect run
-~~~~~~~~~~
-
-If you have a script that can tell if the current source code is good
-or bad, you can automatically bisect using:
-
-------------
-$ git bisect run my_script
-------------
-
-Note that the "run" script (`my_script` in the above example) should
-exit with code 0 in case the current source code is good.  Exit with a
-code between 1 and 127 (inclusive), except 125, if the current
-source code is bad.
-
-Any other exit code will abort the automatic bisect process. (A
-program that does "exit(-1)" leaves $? = 255, see exit(3) manual page,
-the value is chopped with "& 0377".)
-
-The special exit code 125 should be used when the current source code
-cannot be tested. If the "run" script exits with this code, the current
-revision will be skipped, see `git bisect skip` above.
-
-You may often find that during bisect you want to have near-constant
-tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
-"revision that does not have this commit needs this patch applied to
-work around other problem this bisection is not interested in")
-applied to the revision being tested.
-
-To cope with such a situation, after the inner git-bisect finds the
-next revision to test, with the "run" script, you can apply that tweak
-before compiling, run the real test, and after the test decides if the
-revision (possibly with the needed tweaks) passed the test, rewind the
-tree to the pristine state.  Finally the "run" script can exit with
-the status of the real test to let "git bisect run" command loop to
-know the outcome.
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
--------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-blame.txt

@@ -1,195 +0,0 @@
-git-blame(1)
-============
-
-NAME
-----
-git-blame - Show what revision and author last modified each line of a file
-
-SYNOPSIS
---------
-[verse]
-'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
-            [-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
-            [<rev> | --contents <file>] [--] <file>
-
-DESCRIPTION
------------
-
-Annotates each line in the given file with information from the revision which
-last modified the line. Optionally, start annotating from the given revision.
-
-Also it can limit the range of lines annotated.
-
-This report doesn't tell you anything about lines which have been deleted or
-replaced; you need to use a tool such as linkgit:git-diff[1] or the "pickaxe"
-interface briefly mentioned in the following paragraph.
-
-Apart from supporting file annotation, git also supports searching the
-development history for when a code snippet occurred in a change. This makes it
-possible to track when a code snippet was added to a file, moved or copied
-between files, and eventually deleted or replaced. It works by searching for
-a text string in the diff. A small example:
-
------------------------------------------------------------------------------
-$ git log --pretty=oneline -S'blame_usage'
-5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
-ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
------------------------------------------------------------------------------
-
-OPTIONS
--------
-include::blame-options.txt[]
-
--c::
-	Use the same output mode as linkgit:git-annotate[1] (Default: off).
-
---score-debug::
-	Include debugging information related to the movement of
-	lines between files (see `-C`) and lines moved within a
-	file (see `-M`).  The first number listed is the score.
-	This is the number of alphanumeric characters detected
-	to be moved between or within files.  This must be above
-	a certain threshold for git-blame to consider those lines
-	of code to have been moved.
-
--f, --show-name::
-	Show filename in the original commit.  By default
-	filename is shown if there is any line that came from a
-	file with different name, due to rename detection.
-
--n, --show-number::
-	Show line number in the original commit (Default: off).
-
--s::
-	Suppress author name and timestamp from the output.
-
--w::
-	Ignore whitespace when comparing parent's version and
-	child's to find where the lines came from.
-
-
-THE PORCELAIN FORMAT
---------------------
-
-In this format, each line is output after a header; the
-header at the minimum has the first line which has:
-
-- 40-byte SHA-1 of the commit the line is attributed to;
-- the line number of the line in the original file;
-- the line number of the line in the final file;
-- on a line that starts a group of line from a different
-  commit than the previous one, the number of lines in this
-  group.  On subsequent lines this field is absent.
-
-This header line is followed by the following information
-at least once for each commit:
-
-- author name ("author"), email ("author-mail"), time
-  ("author-time"), and timezone ("author-tz"); similarly
-  for committer.
-- filename in the commit the line is attributed to.
-- the first line of the commit log message ("summary").
-
-The contents of the actual line is output after the above
-header, prefixed by a TAB. This is to allow adding more
-header elements later.
-
-
-SPECIFYING RANGES
------------------
-
-Unlike `git-blame` and `git-annotate` in older git, the extent
-of annotation can be limited to both line ranges and revision
-ranges.  When you are interested in finding the origin for
-ll. 40-60 for file `foo`, you can use `-L` option like these
-(they mean the same thing -- both ask for 21 lines starting at
-line 40):
-
-	git blame -L 40,60 foo
-	git blame -L 40,+21 foo
-
-Also you can use regular expression to specify the line range.
-
-	git blame -L '/^sub hello {/,/^}$/' foo
-
-would limit the annotation to the body of `hello` subroutine.
-
-When you are not interested in changes older than the version
-v2.6.18, or changes older than 3 weeks, you can use revision
-range specifiers  similar to `git-rev-list`:
-
-	git blame v2.6.18.. -- foo
-	git blame --since=3.weeks -- foo
-
-When revision range specifiers are used to limit the annotation,
-lines that have not changed since the range boundary (either the
-commit v2.6.18 or the most recent commit that is more than 3
-weeks old in the above example) are blamed for that range
-boundary commit.
-
-A particularly useful way is to see if an added file have lines
-created by copy-and-paste from existing files.  Sometimes this
-indicates that the developer was being sloppy and did not
-refactor the code properly.  You can first find the commit that
-introduced the file with:
-
-	git log --diff-filter=A --pretty=short -- foo
-
-and then annotate the change between the commit and its
-parents, using `commit{caret}!` notation:
-
-	git blame -C -C -f $commit^! -- foo
-
-
-INCREMENTAL OUTPUT
-------------------
-
-When called with `--incremental` option, the command outputs the
-result as it is built.  The output generally will talk about
-lines touched by more recent commits first (i.e. the lines will
-be annotated out of order) and is meant to be used by
-interactive viewers.
-
-The output format is similar to the Porcelain format, but it
-does not contain the actual lines from the file that is being
-annotated.
-
-. Each blame entry always starts with a line of:
-
-	<40-byte hex sha1> <sourceline> <resultline> <num_lines>
-+
-Line numbers count from 1.
-
-. The first time that commit shows up in the stream, it has various
-  other information about it printed out with a one-word tag at the
-  beginning of each line about that "extended commit info" (author,
-  email, committer, dates, summary etc).
-
-. Unlike Porcelain format, the filename information is always
-  given and terminates the entry:
-
-	"filename" <whitespace-quoted-filename-goes-here>
-+
-and thus it's really quite easy to parse for some line- and word-oriented
-parser (which should be quite natural for most scripting languages).
-+
-[NOTE]
-For people who do parsing: to make it more robust, just ignore any
-lines in between the first and last one ("<sha1>" and "filename" lines)
-where you don't recognize the tag-words (or care about that particular
-one) at the beginning of the "extended information" lines. That way, if
-there is ever added information (like the commit encoding or extended
-commit commentary), a blame viewer won't ever care.
-
-
-SEE ALSO
---------
-linkgit:git-annotate[1]
-
-AUTHOR
-------
-Written by Junio C Hamano <junkio@cox.net>
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-branch.txt

@@ -1,191 +0,0 @@
-git-branch(1)
-=============
-
-NAME
-----
-git-branch - List, create, or delete branches
-
-SYNOPSIS
---------
-[verse]
-'git-branch' [--color | --no-color] [-r | -a]
-	   [-v [--abbrev=<length> | --no-abbrev]]
-	   [--contains <commit>]
-'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
-'git-branch' (-m | -M) [<oldbranch>] <newbranch>
-'git-branch' (-d | -D) [-r] <branchname>...
-
-DESCRIPTION
------------
-With no arguments given a list of existing branches
-will be shown, the current branch will be highlighted with an asterisk.
-Option `-r` causes the remote-tracking branches to be listed,
-and option `-a` shows both.
-With `--contains <commit>`, shows only the branches that
-contains the named commit (in other words, the branches whose
-tip commits are descendant of the named commit).
-
-In its second form, a new branch named <branchname> will be created.
-It will start out with a head equal to the one given as <start-point>.
-If no <start-point> is given, the branch will be created with a head
-equal to that of the currently checked out branch.
-
-Note that this will create the new branch, but it will not switch the
-working tree to it; use "git checkout <newbranch>" to switch to the
-new branch.
-
-When a local branch is started off a remote branch, git sets up the
-branch so that linkgit:git-pull[1] will appropriately merge from that
-remote branch.  If this behavior is not desired, it is possible to
-disable it using the global `branch.autosetupmerge` configuration
-flag.  That setting can be overridden by using the `--track`
-and `--no-track` options.
-
-With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
-If <oldbranch> had a corresponding reflog, it is renamed to match
-<newbranch>, and a reflog entry is created to remember the branch
-renaming. If <newbranch> exists, -M must be used to force the rename
-to happen.
-
-With a `-d` or `-D` option, `<branchname>` will be deleted.  You may
-specify more than one branch for deletion.  If the branch currently
-has a reflog then the reflog will also be deleted.
-
-Use -r together with -d to delete remote-tracking branches. Note, that it
-only makes sense to delete remote-tracking branches if they no longer exist
-in remote repository or if linkgit:git-fetch[1] was configured not to fetch
-them again. See also 'prune' subcommand of linkgit:git-remote[1] for way to
-clean up all obsolete remote-tracking branches.
-
-
-OPTIONS
--------
--d::
-	Delete a branch. The branch must be fully merged in HEAD.
-
--D::
-	Delete a branch irrespective of its merged status.
-
--l::
-	Create the branch's reflog.  This activates recording of
-	all changes made to the branch ref, enabling use of date
-	based sha1 expressions such as "<branchname>@\{yesterday}".
-
--f::
-	Force the creation of a new branch even if it means deleting
-	a branch that already exists with the same name.
-
--m::
-	Move/rename a branch and the corresponding reflog.
-
--M::
-	Move/rename a branch even if the new branchname already exists.
-
---color::
-	Color branches to highlight current, local, and remote branches.
-
---no-color::
-	Turn off branch colors, even when the configuration file gives the
-	default to color output.
-
--r::
-	List or delete (if used with -d) the remote-tracking branches.
-
--a::
-	List both remote-tracking branches and local branches.
-
--v, --verbose::
-	Show sha1 and commit subject line for each head.
-
---abbrev=<length>::
-	Alter minimum display length for sha1 in output listing,
-	default value is 7.
-
---no-abbrev::
-	Display the full sha1s in output listing rather than abbreviating them.
-
---track::
-	Set up configuration so that git-pull will automatically
-	retrieve data from the remote branch.  Use this if you always
-	pull from the same remote branch into the new branch, or if you
-	don't want to use "git pull <repository> <refspec>" explicitly.
-	This behavior is the default.  Set the
-	branch.autosetupmerge configuration variable to false if you
-	want git-checkout and git-branch to always behave as if
-	'--no-track' were given.
-
---no-track::
-	When a branch is created off a remote branch,
-	set up configuration so that git-pull will not retrieve data
-	from the remote branch, ignoring the branch.autosetupmerge
-	configuration variable.
-
-<branchname>::
-	The name of the branch to create or delete.
-	The new branch name must pass all checks defined by
-	linkgit:git-check-ref-format[1].  Some of these checks
-	may restrict the characters allowed in a branch name.
-
-<start-point>::
-	The new branch will be created with a HEAD equal to this.  It may
-	be given as a branch name, a commit-id, or a tag.  If this option
-	is omitted, the current branch is assumed.
-
-<oldbranch>::
-	The name of an existing branch to rename.
-
-<newbranch>::
-	The new name for an existing branch. The same restrictions as for
-	<branchname> applies.
-
-
-Examples
---------
-
-Start development off of a known tag::
-+
-------------
-$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
-$ cd my2.6
-$ git branch my2.6.14 v2.6.14   <1>
-$ git checkout my2.6.14
-------------
-+
-<1> This step and the next one could be combined into a single step with
-"checkout -b my2.6.14 v2.6.14".
-
-Delete unneeded branch::
-+
-------------
-$ git clone git://git.kernel.org/.../git.git my.git
-$ cd my.git
-$ git branch -d -r origin/todo origin/html origin/man   <1>
-$ git branch -D test                                    <2>
-------------
-+
-<1> Delete remote-tracking branches "todo", "html", "man". Next 'fetch' or
-'pull' will create them again unless you configure them not to. See
-linkgit:git-fetch[1].
-<2> Delete "test" branch even if the "master" branch (or whichever branch is
-currently checked out) does not have all commits from test branch.
-
-
-Notes
------
-
-If you are creating a branch that you want to immediately checkout, it's
-easier to use the git checkout command with its `-b` option to create
-a branch and check it out with a single command.
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-bundle.txt

@@ -1,148 +0,0 @@
-git-bundle(1)
-=============
-
-NAME
-----
-git-bundle - Move objects and refs by archive
-
-
-SYNOPSIS
---------
-[verse]
-'git-bundle' create <file> [git-rev-list args]
-'git-bundle' verify <file>
-'git-bundle' list-heads <file> [refname...]
-'git-bundle' unbundle <file> [refname...]
-
-DESCRIPTION
------------
-
-Some workflows require that one or more branches of development on one
-machine be replicated on another machine, but the two machines cannot
-be directly connected so the interactive git protocols (git, ssh,
-rsync, http) cannot be used.  This command provides support for
-git-fetch and git-pull to operate by packaging objects and references
-in an archive at the originating machine, then importing those into
-another repository using linkgit:git-fetch[1] and linkgit:git-pull[1]
-after moving the archive by some means (i.e., by sneakernet).  As no
-direct connection between repositories exists, the user must specify a
-basis for the bundle that is held by the destination repository: the
-bundle assumes that all objects in the basis are already in the
-destination repository.
-
-OPTIONS
--------
-
-create <file>::
-       Used to create a bundle named 'file'.  This requires the
-       git-rev-list arguments to define the bundle contents.
-
-verify <file>::
-       Used to check that a bundle file is valid and will apply
-       cleanly to the current repository.  This includes checks on the
-       bundle format itself as well as checking that the prerequisite
-       commits exist and are fully linked in the current repository.
-       git-bundle prints a list of missing commits, if any, and exits
-       with non-zero status.
-
-list-heads <file>::
-       Lists the references defined in the bundle.  If followed by a
-       list of references, only references matching those given are
-       printed out.
-
-unbundle <file>::
-       Passes the objects in the bundle to linkgit:git-index-pack[1]
-       for storage in the repository, then prints the names of all
-       defined references. If a reflist is given, only references
-       matching those in the given list are printed. This command is
-       really plumbing, intended to be called only by
-       linkgit:git-fetch[1].
-
-[git-rev-list-args...]::
-       A list of arguments, acceptable to git-rev-parse and
-       git-rev-list, that specify the specific objects and references
-       to transport.  For example, "master~10..master" causes the
-       current master reference to be packaged along with all objects
-       added since its 10th ancestor commit.  There is no explicit
-       limit to the number of references and objects that may be
-       packaged.
-
-
-[refname...]::
-       A list of references used to limit the references reported as
-       available. This is principally of use to git-fetch, which
-       expects to receive only those references asked for and not
-       necessarily everything in the pack (in this case, git-bundle is
-       acting like linkgit:git-fetch-pack[1]).
-
-SPECIFYING REFERENCES
----------------------
-
-git-bundle will only package references that are shown by
-git-show-ref: this includes heads, tags, and remote heads.  References
-such as master~1 cannot be packaged, but are perfectly suitable for
-defining the basis.  More than one reference may be packaged, and more
-than one basis can be specified.  The objects packaged are those not
-contained in the union of the given bases.  Each basis can be
-specified explicitly (e.g., ^master~10), or implicitly (e.g.,
-master~10..master, master --since=10.days.ago).
-
-It is very important that the basis used be held by the destination.
-It is okay to err on the side of conservatism, causing the bundle file
-to contain objects already in the destination as these are ignored
-when unpacking at the destination.
-
-EXAMPLE
--------
-
-Assume two repositories exist as R1 on machine A, and R2 on machine B.
-For whatever reason, direct connection between A and B is not allowed,
-but we can move data from A to B via some mechanism (CD, email, etc).
-We want to update R2 with developments made on branch master in R1.
-We set a tag in R1 (lastR2bundle) after the previous such transport,
-and move it afterwards to help build the bundle.
-
-in R1 on A:
-
-------------
-$ git-bundle create mybundle master ^lastR2bundle
-$ git tag -f lastR2bundle master
-------------
-
-(move mybundle from A to B by some mechanism)
-
-in R2 on B:
-
-------------
-$ git-bundle verify mybundle
-$ git-fetch mybundle  refspec
-------------
-
-where refspec is refInBundle:localRef
-
-
-Also, with something like this in your config:
-
-[remote "bundle"]
-    url = /home/me/tmp/file.bdl
-    fetch = refs/heads/*:refs/remotes/origin/*
-
-You can first sneakernet the bundle file to ~/tmp/file.bdl and
-then these commands:
-
-------------
-$ git ls-remote bundle
-$ git fetch bundle
-$ git pull bundle
-------------
-
-would treat it as if it is talking with a remote side over the
-network.
-
-Author
-------
-Written by Mark Levedahl <mdl123@verizon.net>
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-cat-file.txt

@@ -1,73 +0,0 @@
-git-cat-file(1)
-===============
-
-NAME
-----
-git-cat-file - Provide content or type/size information for repository objects
-
-
-SYNOPSIS
---------
-'git-cat-file' [-t | -s | -e | -p | <type>] <object>
-
-DESCRIPTION
------------
-Provides content or type of objects in the repository. The type
-is required unless '-t' or '-p' is used to find the object type,
-or '-s' is used to find the object size.
-
-OPTIONS
--------
-<object>::
-	The name of the object to show.
-	For a more complete list of ways to spell object names, see
-	"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
-
--t::
-	Instead of the content, show the object type identified by
-	<object>.
-
--s::
-	Instead of the content, show the object size identified by
-	<object>.
-
--e::
-	Suppress all output; instead exit with zero status if <object>
-	exists and is a valid object.
-
--p::
-	Pretty-print the contents of <object> based on its type.
-
-<type>::
-	Typically this matches the real type of <object> but asking
-	for a type that can trivially be dereferenced from the given
-	<object> is also permitted.  An example is to ask for a
-	"tree" with <object> being a commit object that contains it,
-	or to ask for a "blob" with <object> being a tag object that
-	points at it.
-
-OUTPUT
-------
-If '-t' is specified, one of the <type>.
-
-If '-s' is specified, the size of the <object> in bytes.
-
-If '-e' is specified, no output.
-
-If '-p' is specified, the contents of <object> are pretty-printed.
-
-Otherwise the raw (though uncompressed) contents of the <object> will
-be returned.
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-check-attr.txt

@@ -1,41 +0,0 @@
-git-check-attr(1)
-=================
-
-NAME
-----
-git-check-attr - Display gitattributes information.
-
-
-SYNOPSIS
---------
-'git-check-attr' attr... [--] pathname...
-
-DESCRIPTION
------------
-For every pathname, this command will list if each attr is 'unspecified',
-'set', or 'unset' as a gitattribute on that pathname.
-
-OPTIONS
--------
-\--::
-	Interpret all preceding arguments as attributes, and all following
-	arguments as path names. If not supplied, only the first argument will
-	be treated as an attribute.
-
-
-SEE ALSO
---------
-linkgit:gitattributes[5].
-
-
-Author
-------
-Written by Junio C Hamano <junkio@cox.net>
-
-Documentation
---------------
-Documentation by James Bowes.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-check-ref-format.txt

@@ -1,55 +0,0 @@
-git-check-ref-format(1)
-=======================
-
-NAME
-----
-git-check-ref-format - Make sure ref name is well formed
-
-SYNOPSIS
---------
-'git-check-ref-format' <refname>
-
-DESCRIPTION
------------
-Checks if a given 'refname' is acceptable, and exits non-zero if
-it is not.
-
-A reference is used in git to specify branches and tags.  A
-branch head is stored under `$GIT_DIR/refs/heads` directory, and
-a tag is stored under `$GIT_DIR/refs/tags` directory.  git
-imposes the following rules on how refs are named:
-
-. It can include slash `/` for hierarchical (directory)
-  grouping, but no slash-separated component can begin with a
-  dot `.`;
-
-. It cannot have two consecutive dots `..` anywhere;
-
-. It cannot have ASCII control character (i.e. bytes whose
-  values are lower than \040, or \177 `DEL`), space, tilde `~`,
-  caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
-  or open bracket `[` anywhere;
-
-. It cannot end with a slash `/`.
-
-These rules makes it easy for shell script based tools to parse
-refnames, pathname expansion by the shell when a refname is used
-unquoted (by mistake), and also avoids ambiguities in certain
-refname expressions (see linkgit:git-rev-parse[1]).  Namely:
-
-. double-dot `..` are often used as in `ref1..ref2`, and in some
-  context this notation means `{caret}ref1 ref2` (i.e. not in
-  ref1 and in ref2).
-
-. tilde `~` and caret `{caret}` are used to introduce postfix
-  'nth parent' and 'peel onion' operation.
-
-. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
-  value and store it in dstref" in fetch and push operations.
-  It may also be used to select a specific object such as with
-  linkgit:git-cat-file[1] "git-cat-file blob v1.3.3:refs.c".
-
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-checkout-index.txt

@@ -1,184 +0,0 @@
-git-checkout-index(1)
-=====================
-
-NAME
-----
-git-checkout-index - Copy files from the index to the working tree
-
-
-SYNOPSIS
---------
-[verse]
-'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
-		   [--stage=<number>|all]
-		   [--temp]
-		   [-z] [--stdin]
-		   [--] [<file>]\*
-
-DESCRIPTION
------------
-Will copy all files listed from the index to the working directory
-(not overwriting existing files).
-
-OPTIONS
--------
--u|--index::
-	update stat information for the checked out entries in
-	the index file.
-
--q|--quiet::
-	be quiet if files exist or are not in the index
-
--f|--force::
-	forces overwrite of existing files
-
--a|--all::
-	checks out all files in the index.  Cannot be used
-	together with explicit filenames.
-
--n|--no-create::
-	Don't checkout new files, only refresh files already checked
-	out.
-
---prefix=<string>::
-	When creating files, prepend <string> (usually a directory
-	including a trailing /)
-
---stage=<number>|all::
-	Instead of checking out unmerged entries, copy out the
-	files from named stage.  <number> must be between 1 and 3.
-	Note: --stage=all automatically implies --temp.
-
---temp::
-	Instead of copying the files to the working directory
-	write the content to temporary files.  The temporary name
-	associations will be written to stdout.
-
---stdin::
-	Instead of taking list of paths from the command line,
-	read list of paths from the standard input.  Paths are
-	separated by LF (i.e. one path per line) by default.
-
--z::
-	Only meaningful with `--stdin`; paths are separated with
-	NUL character instead of LF.
-
-\--::
-	Do not interpret any more arguments as options.
-
-The order of the flags used to matter, but not anymore.
-
-Just doing `git-checkout-index` does nothing. You probably meant
-`git-checkout-index -a`. And if you want to force it, you want
-`git-checkout-index -f -a`.
-
-Intuitiveness is not the goal here. Repeatability is. The reason for
-the "no arguments means no work" behavior is that from scripts you are
-supposed to be able to do:
-
-----------------
-$ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
-----------------
-
-which will force all existing `*.h` files to be replaced with their
-cached copies. If an empty command line implied "all", then this would
-force-refresh everything in the index, which was not the point.  But
-since git-checkout-index accepts --stdin it would be faster to use:
-
-----------------
-$ find . -name '*.h' -print0 | git-checkout-index -f -z --stdin
-----------------
-
-The `--` is just a good idea when you know the rest will be filenames;
-it will prevent problems with a filename of, for example,  `-a`.
-Using `--` is probably a good policy in scripts.
-
-
-Using --temp or --stage=all
----------------------------
-When `--temp` is used (or implied by `--stage=all`)
-`git-checkout-index` will create a temporary file for each index
-entry being checked out.  The index will not be updated with stat
-information.  These options can be useful if the caller needs all
-stages of all unmerged entries so that the unmerged files can be
-processed by an external merge tool.
-
-A listing will be written to stdout providing the association of
-temporary file names to tracked path names.  The listing format
-has two variations:
-
-    . tempname TAB path RS
-+
-The first format is what gets used when `--stage` is omitted or
-is not `--stage=all`. The field tempname is the temporary file
-name holding the file content and path is the tracked path name in
-the index.  Only the requested entries are output.
-
-    . stage1temp SP stage2temp SP stage3tmp TAB path RS
-+
-The second format is what gets used when `--stage=all`.  The three
-stage temporary fields (stage1temp, stage2temp, stage3temp) list the
-name of the temporary file if there is a stage entry in the index
-or `.` if there is no stage entry.  Paths which only have a stage 0
-entry will always be omitted from the output.
-
-In both formats RS (the record separator) is newline by default
-but will be the null byte if -z was passed on the command line.
-The temporary file names are always safe strings; they will never
-contain directory separators or whitespace characters.  The path
-field is always relative to the current directory and the temporary
-file names are always relative to the top level directory.
-
-If the object being copied out to a temporary file is a symbolic
-link the content of the link will be written to a normal file.  It is
-up to the end-user or the Porcelain to make use of this information.
-
-
-EXAMPLES
---------
-To update and refresh only the files already checked out::
-+
-----------------
-$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
-----------------
-
-Using `git-checkout-index` to "export an entire tree"::
-	The prefix ability basically makes it trivial to use
-	`git-checkout-index` as an "export as tree" function.
-	Just read the desired tree into the index, and do:
-+
-----------------
-$ git-checkout-index --prefix=git-export-dir/ -a
-----------------
-+
-`git-checkout-index` will "export" the index into the specified
-directory.
-+
-The final "/" is important. The exported name is literally just
-prefixed with the specified string.  Contrast this with the
-following example.
-
-Export files with a prefix::
-+
-----------------
-$ git-checkout-index --prefix=.merged- Makefile
-----------------
-+
-This will check out the currently cached copy of `Makefile`
-into the file `.merged-Makefile`.
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-
-Documentation
---------------
-Documentation by David Greaves,
-Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-checkout.txt

@@ -1,220 +0,0 @@
-git-checkout(1)
-===============
-
-NAME
-----
-git-checkout - Checkout and switch to a branch
-
-SYNOPSIS
---------
-[verse]
-'git-checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
-'git-checkout' [<tree-ish>] <paths>...
-
-DESCRIPTION
------------
-
-When <paths> are not given, this command switches branches by
-updating the index and working tree to reflect the specified
-branch, <branch>, and updating HEAD to be <branch> or, if
-specified, <new_branch>.  Using -b will cause <new_branch> to
-be created; in this case you can use the --track or --no-track
-options, which will be passed to `git branch`.
-
-When <paths> are given, this command does *not* switch
-branches.  It updates the named paths in the working tree from
-the index file (i.e. it runs `git-checkout-index -f -u`), or
-from a named commit.  In
-this case, the `-f` and `-b` options are meaningless and giving
-either of them results in an error.  <tree-ish> argument can be
-used to specify a specific tree-ish (i.e. commit, tag or tree)
-to update the index for the given paths before updating the
-working tree.
-
-
-OPTIONS
--------
--q::
-	Quiet, suppress feedback messages.
-
--f::
-	Proceed even if the index or the working tree differs
-	from HEAD.  This is used to throw away local changes.
-
--b::
-	Create a new branch named <new_branch> and start it at
-	<branch>.  The new branch name must pass all checks defined
-	by linkgit:git-check-ref-format[1].  Some of these checks
-	may restrict the characters allowed in a branch name.
-
---track::
-	When -b is given and a branch is created off a remote branch,
-	set up configuration so that git-pull will automatically
-	retrieve data from the remote branch.  Use this if you always
-	pull from the same remote branch into the new branch, or if you
-	don't want to use "git pull <repository> <refspec>" explicitly.
-	This behavior is the default.  Set the
-	branch.autosetupmerge configuration variable to false if you
-	want git-checkout and git-branch to always behave as if
-	'--no-track' were given.
-
---no-track::
-	When -b is given and a branch is created off a remote branch,
-	set up configuration so that git-pull will not retrieve data
-	from the remote branch, ignoring the branch.autosetupmerge
-	configuration variable.
-
--l::
-	Create the new branch's reflog.  This activates recording of
-	all changes made to the branch ref, enabling use of date
-	based sha1 expressions such as "<branchname>@\{yesterday}".
-
--m::
-	If you have local modifications to one or more files that
-	are different between the current branch and the branch to
-	which you are switching, the command refuses to switch
-	branches in order to preserve your modifications in context.
-	However, with this option, a three-way merge between the current
-	branch, your working tree contents, and the new branch
-	is done, and you will be on the new branch.
-+
-When a merge conflict happens, the index entries for conflicting
-paths are left unmerged, and you need to resolve the conflicts
-and mark the resolved paths with `git add` (or `git rm` if the merge
-should result in deletion of the path).
-
-<new_branch>::
-	Name for the new branch.
-
-<branch>::
-	Branch to checkout; may be any object ID that resolves to a
-	commit.  Defaults to HEAD.
-+
-When this parameter names a non-branch (but still a valid commit object),
-your HEAD becomes 'detached'.
-
-
-Detached HEAD
--------------
-
-It is sometimes useful to be able to 'checkout' a commit that is
-not at the tip of one of your branches.  The most obvious
-example is to check out the commit at a tagged official release
-point, like this:
-
-------------
-$ git checkout v2.6.18
-------------
-
-Earlier versions of git did not allow this and asked you to
-create a temporary branch using `-b` option, but starting from
-version 1.5.0, the above command 'detaches' your HEAD from the
-current branch and directly point at the commit named by the tag
-(`v2.6.18` in the above example).
-
-You can use usual git commands while in this state.  You can use
-`git-reset --hard $othercommit` to further move around, for
-example.  You can make changes and create a new commit on top of
-a detached HEAD.  You can even create a merge by using `git
-merge $othercommit`.
-
-The state you are in while your HEAD is detached is not recorded
-by any branch (which is natural --- you are not on any branch).
-What this means is that you can discard your temporary commits
-and merges by switching back to an existing branch (e.g. `git
-checkout master`), and a later `git prune` or `git gc` would
-garbage-collect them.  If you did this by mistake, you can ask
-the reflog for HEAD where you were, e.g.
-
-------------
-$ git log -g -2 HEAD
-------------
-
-
-EXAMPLES
---------
-
-. The following sequence checks out the `master` branch, reverts
-the `Makefile` to two revisions back, deletes hello.c by
-mistake, and gets it back from the index.
-+
-------------
-$ git checkout master             <1>
-$ git checkout master~2 Makefile  <2>
-$ rm -f hello.c
-$ git checkout hello.c            <3>
-------------
-+
-<1> switch branch
-<2> take out a file out of other commit
-<3> restore hello.c from HEAD of current branch
-+
-If you have an unfortunate branch that is named `hello.c`, this
-step would be confused as an instruction to switch to that branch.
-You should instead write:
-+
-------------
-$ git checkout -- hello.c
-------------
-
-. After working in a wrong branch, switching to the correct
-branch would be done using:
-+
-------------
-$ git checkout mytopic
-------------
-+
-However, your "wrong" branch and correct "mytopic" branch may
-differ in files that you have locally modified, in which case,
-the above checkout would fail like this:
-+
-------------
-$ git checkout mytopic
-fatal: Entry 'frotz' not uptodate. Cannot merge.
-------------
-+
-You can give the `-m` flag to the command, which would try a
-three-way merge:
-+
-------------
-$ git checkout -m mytopic
-Auto-merging frotz
-------------
-+
-After this three-way merge, the local modifications are _not_
-registered in your index file, so `git diff` would show you what
-changes you made since the tip of the new branch.
-
-. When a merge conflict happens during switching branches with
-the `-m` option, you would see something like this:
-+
-------------
-$ git checkout -m mytopic
-Auto-merging frotz
-merge: warning: conflicts during merge
-ERROR: Merge conflict in frotz
-fatal: merge program failed
-------------
-+
-At this point, `git diff` shows the changes cleanly merged as in
-the previous example, as well as the changes in the conflicted
-files.  Edit and resolve the conflict and mark it resolved with
-`git add` as usual:
-+
-------------
-$ edit frotz
-$ git add frotz
-------------
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-cherry-pick.txt

@@ -1,78 +0,0 @@
-git-cherry-pick(1)
-==================
-
-NAME
-----
-git-cherry-pick - Apply the change introduced by an existing commit
-
-SYNOPSIS
---------
-'git-cherry-pick' [--edit] [-n] [-m parent-number] [-x] <commit>
-
-DESCRIPTION
------------
-Given one existing commit, apply the change the patch introduces, and record a
-new commit that records it.  This requires your working tree to be clean (no
-modifications from the HEAD commit).
-
-OPTIONS
--------
-<commit>::
-	Commit to cherry-pick.
-	For a more complete list of ways to spell commits, see
-	"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
-
--e|--edit::
-	With this option, `git-cherry-pick` will let you edit the commit
-	message prior to committing.
-
--x::
-	When recording the commit, append to the original commit
-	message a note that indicates which commit this change
-	was cherry-picked from.  Append the note only for cherry
-	picks without conflicts.  Do not use this option if
-	you are cherry-picking from your private branch because
-	the information is useless to the recipient.  If on the
-	other hand you are cherry-picking between two publicly
-	visible branches (e.g. backporting a fix to a
-	maintenance branch for an older release from a
-	development branch), adding this information can be
-	useful.
-
--r::
-	It used to be that the command defaulted to do `-x`
-	described above, and `-r` was to disable it.  Now the
-	default is not to do `-x` so this option is a no-op.
-
--m parent-number|--mainline parent-number::
-	Usually you cannot revert a merge because you do not know which
-	side of the merge should be considered the mainline.  This
-	option specifies the parent number (starting from 1) of
-	the mainline and allows cherry-pick to replay the change
-	relative to the specified parent.
-
--n|--no-commit::
-	Usually the command automatically creates a commit with
-	a commit log message stating which commit was
-	cherry-picked.  This flag applies the change necessary
-	to cherry-pick the named commit to your working tree,
-	but does not make the commit.  In addition, when this
-	option is used, your working tree does not have to match
-	the HEAD commit.  The cherry-pick is done against the
-	beginning state of your working tree.
-+
-This is useful when cherry-picking more than one commits'
-effect to your working tree in a row.
-
-
-Author
-------
-Written by Junio C Hamano <junkio@cox.net>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-cherry.txt

@@ -1,69 +0,0 @@
-git-cherry(1)
-=============
-
-NAME
-----
-git-cherry - Find commits not merged upstream
-
-SYNOPSIS
---------
-'git-cherry' [-v] <upstream> [<head>] [<limit>]
-
-DESCRIPTION
------------
-The changeset (or "diff") of each commit between the fork-point and <head>
-is compared against each commit between the fork-point and <upstream>.
-
-Every commit that doesn't exist in the <upstream> branch
-has its id (sha1) reported, prefixed by a symbol.  The ones that have
-equivalent change already
-in the <upstream> branch are prefixed with a minus (-) sign, and those
-that only exist in the <head> branch are prefixed with a plus (+) symbol:
-
-               __*__*__*__*__> <upstream>
-              /
-    fork-point
-              \__+__+__-__+__+__-__+__> <head>
-
-
-If a <limit> has been given then the commits along the <head> branch up
-to and including <limit> are not reported:
-
-               __*__*__*__*__> <upstream>
-              /
-    fork-point
-              \__*__*__<limit>__-__+__> <head>
-
-
-Because git-cherry compares the changeset rather than the commit id
-(sha1), you can use git-cherry to find out if a commit you made locally
-has been applied <upstream> under a different commit id.  For example,
-this will happen if you're feeding patches <upstream> via email rather
-than pushing or pulling commits directly.
-
-
-OPTIONS
--------
--v::
-	Verbose.
-
-<upstream>::
-	Upstream branch to compare against.
-
-<head>::
-	Working branch; defaults to HEAD.
-
-<limit>::
-	Do not report commits up to (and including) limit.
-
-Author
-------
-Written by Junio C Hamano <junkio@cox.net>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-citool.txt

@@ -1,32 +0,0 @@
-git-citool(1)
-=============
-
-NAME
-----
-git-citool - Graphical alternative to git-commit
-
-SYNOPSIS
---------
-'git citool'
-
-DESCRIPTION
------------
-A Tcl/Tk based graphical interface to review modified files, stage
-them into the index, enter a commit message and record the new
-commit onto the current branch.  This interface is an alternative
-to the less interactive linkgit:git-commit[1] program.
-
-git-citool is actually a standard alias for 'git gui citool'.
-See linkgit:git-gui[1] for more details.
-
-Author
-------
-Written by Shawn O. Pearce <spearce@spearce.org>.
-
-Documentation
---------------
-Documentation by Shawn O. Pearce <spearce@spearce.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-clean.txt

@@ -1,57 +0,0 @@
-git-clean(1)
-============
-
-NAME
-----
-git-clean - Remove untracked files from the working tree
-
-SYNOPSIS
---------
-[verse]
-'git-clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...
-
-DESCRIPTION
------------
-Removes files unknown to git.  This allows to clean the working tree
-from files that are not under version control.  If the '-x' option is
-specified, ignored files are also removed, allowing to remove all
-build products.
-When optional `<paths>...` arguments are given, the paths
-affected are further limited to those that match them.
-
-
-OPTIONS
--------
--d::
-	Remove untracked directories in addition to untracked files.
-
--f::
-	If the git configuration specifies clean.requireForce as true,
-	git-clean will refuse to run unless given -f or -n.
-
--n::
-	Don't actually remove anything, just show what would be done.
-
--q::
-	Be quiet, only report errors, but not the files that are
-	successfully removed.
-
--x::
-	Don't use the ignore rules.  This allows removing all untracked
-	files, including build products.  This can be used (possibly in
-	conjunction with linkgit:git-reset[1]) to create a pristine
-	working directory to test a clean build.
-
--X::
-	Remove only files ignored by git.  This may be useful to rebuild
-	everything from scratch, but keep manually created files.
-
-
-Author
-------
-Written by Pavel Roskin <proski@gnu.org>
-
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-clone.txt

@@ -1,203 +0,0 @@
-git-clone(1)
-============
-
-NAME
-----
-git-clone - Clone a repository into a new directory
-
-
-SYNOPSIS
---------
-[verse]
-'git-clone' [--template=<template_directory>]
-	  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
-	  [-o <name>] [-u <upload-pack>] [--reference <repository>]
-	  [--depth <depth>] [--] <repository> [<directory>]
-
-DESCRIPTION
------------
-
-Clones a repository into a newly created directory, creates
-remote-tracking branches for each branch in the cloned repository
-(visible using `git branch -r`), and creates and checks out an initial
-branch equal to the cloned repository's currently active branch.
-
-After the clone, a plain `git fetch` without arguments will update
-all the remote-tracking branches, and a `git pull` without
-arguments will in addition merge the remote master branch into the
-current master branch, if any.
-
-This default configuration is achieved by creating references to
-the remote branch heads under `$GIT_DIR/refs/remotes/origin` and
-by initializing `remote.origin.url` and `remote.origin.fetch`
-configuration variables.
-
-
-OPTIONS
--------
---local::
--l::
-	When the repository to clone from is on a local machine,
-	this flag bypasses normal "git aware" transport
-	mechanism and clones the repository by making a copy of
-	HEAD and everything under objects and refs directories.
-	The files under `.git/objects/` directory are hardlinked
-	to save space when possible.  This is now the default when
-	the source repository is specified with `/path/to/repo`
-	syntax, so it essentially is a no-op option.  To force
-	copying instead of hardlinking (which may be desirable
-	if you are trying to make a back-up of your repository),
-	but still avoid the usual "git aware" transport
-	mechanism, `--no-hardlinks` can be used.
-
---no-hardlinks::
-	Optimize the cloning process from a repository on a
-	local filesystem by copying files under `.git/objects`
-	directory.
-
---shared::
--s::
-	When the repository to clone is on the local machine,
-	instead of using hard links, automatically setup
-	.git/objects/info/alternates to share the objects
-	with the source repository.  The resulting repository
-	starts out without any object of its own.
-+
-*NOTE*: this is a possibly dangerous operation; do *not* use
-it unless you understand what it does. If you clone your
-repository using this option, then delete branches in the
-source repository and then run linkgit:git-gc[1] using the
-'--prune' option in the source repository, it may remove
-objects which are referenced by the cloned repository.
-
-
-
---reference <repository>::
-	If the reference repository is on the local machine
-	automatically setup .git/objects/info/alternates to
-	obtain objects from the reference repository.  Using
-	an already existing repository as an alternate will
-	require fewer objects to be copied from the repository
-	being cloned, reducing network and local storage costs.
-
---quiet::
--q::
-	Operate quietly.  This flag is passed to "rsync" and
-	"git-fetch-pack" commands when given.
-
---no-checkout::
--n::
-	No checkout of HEAD is performed after the clone is complete.
-
---bare::
-	Make a 'bare' GIT repository.  That is, instead of
-	creating `<directory>` and placing the administrative
-	files in `<directory>/.git`, make the `<directory>`
-	itself the `$GIT_DIR`. This obviously implies the `-n`
-	because there is nowhere to check out the working tree.
-	Also the branch heads at the remote are copied directly
-	to corresponding local branch heads, without mapping
-	them to `refs/remotes/origin/`.  When this option is
-	used, neither remote-tracking branches nor the related
-	configuration variables are created.
-
---origin <name>::
--o <name>::
-	Instead of using the remote name 'origin' to keep track
-	of the upstream repository, use <name> instead.
-
---upload-pack <upload-pack>::
--u <upload-pack>::
-	When given, and the repository to clone from is handled
-	by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
-	the command to specify non-default path for the command
-	run on the other end.
-
---template=<template_directory>::
-	Specify the directory from which templates will be used;
-	if unset the templates are taken from the installation
-	defined default, typically `/usr/share/git-core/templates`.
-
---depth <depth>::
-	Create a 'shallow' clone with a history truncated to the
-	specified number of revisions.  A shallow repository has a
-	number of limitations (you cannot clone or fetch from
-	it, nor push from nor into it), but is adequate if you
-	are only interested in the recent history of a large project
-	with a long history, and would want to send in fixes
-	as patches.
-
-<repository>::
-	The (possibly remote) repository to clone from.  See the
-	<<URLS,URLS>> section below for more information on specifying
-	repositories.
-
-<directory>::
-	The name of a new directory to clone into.  The "humanish"
-	part of the source repository is used if no directory is
-	explicitly given ("repo" for "/path/to/repo.git" and "foo"
-	for "host.xz:foo/.git").  Cloning into an existing directory
-	is not allowed.
-
-:git-clone: 1
-include::urls.txt[]
-
-Examples
---------
-
-Clone from upstream::
-+
-------------
-$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
-$ cd my2.6
-$ make
-------------
-
-
-Make a local clone that borrows from the current directory, without checking things out::
-+
-------------
-$ git clone -l -s -n . ../copy
-$ cd ../copy
-$ git show-branch
-------------
-
-
-Clone from upstream while borrowing from an existing local directory::
-+
-------------
-$ git clone --reference my2.6 \
-	git://git.kernel.org/pub/scm/.../linux-2.7 \
-	my2.7
-$ cd my2.7
-------------
-
-
-Create a bare repository to publish your changes to the public::
-+
-------------
-$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
-------------
-
-
-Create a repository on the kernel.org machine that borrows from Linus::
-+
-------------
-$ git clone --bare -l -s /pub/scm/.../torvalds/linux-2.6.git \
-    /pub/scm/.../me/subsys-2.6.git
-------------
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-commit-tree.txt

@@ -1,106 +0,0 @@
-git-commit-tree(1)
-==================
-
-NAME
-----
-git-commit-tree - Create a new commit object
-
-
-SYNOPSIS
---------
-'git-commit-tree' <tree> [-p <parent commit>]\* < changelog
-
-DESCRIPTION
------------
-This is usually not what an end user wants to run directly.  See
-linkgit:git-commit[1] instead.
-
-Creates a new commit object based on the provided tree object and
-emits the new commit object id on stdout. If no parent is given then
-it is considered to be an initial tree.
-
-A commit object usually has 1 parent (a commit after a change) or up
-to 16 parents.  More than one parent represents a merge of branches
-that led to them.
-
-While a tree represents a particular directory state of a working
-directory, a commit represents that state in "time", and explains how
-to get there.
-
-Normally a commit would identify a new "HEAD" state, and while git
-doesn't care where you save the note about that state, in practice we
-tend to just write the result to the file that is pointed at by
-`.git/HEAD`, so that we can always see what the last committed
-state was.
-
-OPTIONS
--------
-<tree>::
-	An existing tree object
-
--p <parent commit>::
-	Each '-p' indicates the id of a parent commit object.
-
-
-Commit Information
-------------------
-
-A commit encapsulates:
-
-- all parent object ids
-- author name, email and date
-- committer name and email and the commit time.
-
-While parent object ids are provided on the command line, author and
-committer information is taken from the following environment variables,
-if set:
-
-	GIT_AUTHOR_NAME
-	GIT_AUTHOR_EMAIL
-	GIT_AUTHOR_DATE
-	GIT_COMMITTER_NAME
-	GIT_COMMITTER_EMAIL
-	GIT_COMMITTER_DATE
-	EMAIL
-
-(nb "<", ">" and "\n"s are stripped)
-
-In case (some of) these environment variables are not set, the information
-is taken from the configuration items user.name and user.email, or, if not
-present, system user name and fully qualified hostname.
-
-A commit comment is read from stdin. If a changelog
-entry is not provided via "<" redirection, "git-commit-tree" will just wait
-for one to be entered and terminated with ^D.
-
-
-Diagnostics
------------
-You don't exist. Go away!::
-    The passwd(5) gecos field couldn't be read
-Your parents must have hated you!::
-    The password(5) gecos field is longer than a giant static buffer.
-Your sysadmin must hate you!::
-    The password(5) name field is longer than a giant static buffer.
-
-Discussion
-----------
-
-include::i18n.txt[]
-
-See Also
---------
-linkgit:git-write-tree[1]
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-commit.txt

@@ -1,304 +0,0 @@
-git-commit(1)
-=============
-
-NAME
-----
-git-commit - Record changes to the repository
-
-SYNOPSIS
---------
-[verse]
-'git-commit' [-a | --interactive] [-s] [-v] [-u]
-	   [(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
-	   [--allow-empty] [--no-verify] [-e] [--author <author>]
-	   [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
-
-DESCRIPTION
------------
-Use 'git commit' to store the current contents of the index in a new
-commit along with a log message describing the changes you have made.
-
-The content to be added can be specified in several ways:
-
-1. by using linkgit:git-add[1] to incrementally "add" changes to the
-   index before using the 'commit' command (Note: even modified
-   files must be "added");
-
-2. by using linkgit:git-rm[1] to remove files from the working tree
-   and the index, again before using the 'commit' command;
-
-3. by listing files as arguments to the 'commit' command, in which
-   case the commit will ignore changes staged in the index, and instead
-   record the current content of the listed files;
-
-4. by using the -a switch with the 'commit' command to automatically
-   "add" changes from all known files (i.e. all files that are already
-   listed in the index) and to automatically "rm" files in the index
-   that have been removed from the working tree, and then perform the
-   actual commit;
-
-5. by using the --interactive switch with the 'commit' command to decide one
-   by one which files should be part of the commit, before finalizing the
-   operation.  Currently, this is done by invoking `git-add --interactive`.
-
-The linkgit:git-status[1] command can be used to obtain a
-summary of what is included by any of the above for the next
-commit by giving the same set of parameters you would give to
-this command.
-
-If you make a commit and then found a mistake immediately after
-that, you can recover from it with linkgit:git-reset[1].
-
-
-OPTIONS
--------
--a|--all::
-	Tell the command to automatically stage files that have
-	been modified and deleted, but new files you have not
-	told git about are not affected.
-
--c or -C <commit>::
-	Take existing commit object, and reuse the log message
-	and the authorship information (including the timestamp)
-	when creating the commit.  With '-C', the editor is not
-	invoked; with '-c' the user can further edit the commit
-	message.
-
--F <file>::
-	Take the commit message from the given file.  Use '-' to
-	read the message from the standard input.
-
---author <author>::
-	Override the author name used in the commit.  Use
-	`A U Thor <author@example.com>` format.
-
--m <msg>|--message=<msg>::
-	Use the given <msg> as the commit message.
-
--t <file>|--template=<file>::
-	Use the contents of the given file as the initial version
-	of the commit message. The editor is invoked and you can
-	make subsequent changes. If a message is specified using
-	the `-m` or `-F` options, this option has no effect. This
-	overrides the `commit.template` configuration variable.
-
--s|--signoff::
-	Add Signed-off-by line at the end of the commit message.
-
---no-verify::
-	This option bypasses the pre-commit and commit-msg hooks.
-	See also link:hooks.html[hooks].
-
---allow-empty::
-	Usually recording a commit that has the exact same tree as its
-	sole parent commit is a mistake, and the command prevents you
-	from making such a commit.  This option bypasses the safety, and
-	is primarily for use by foreign scm interface scripts.
-
---cleanup=<mode>::
-	This option sets how the commit message is cleaned up.
-	The  '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
-	and 'default'. The 'default' mode will strip leading and
-	trailing empty lines and #commentary from the commit message
-	only if the message is to be edited. Otherwise only whitespace
-	removed. The 'verbatim' mode does not change message at all,
-	'whitespace' removes just leading/trailing whitespace lines
-	and 'strip' removes both whitespace and commentary.
-
--e|--edit::
-	The message taken from file with `-F`, command line with
-	`-m`, and from file with `-C` are usually used as the
-	commit log message unmodified.  This option lets you
-	further edit the message taken from these sources.
-
---amend::
-
-	Used to amend the tip of the current branch. Prepare the tree
-	object you would want to replace the latest commit as usual
-	(this includes the usual -i/-o and explicit paths), and the
-	commit log editor is seeded with the commit message from the
-	tip of the current branch. The commit you create replaces the
-	current tip -- if it was a merge, it will have the parents of
-	the current tip as parents -- so the current top commit is
-	discarded.
-+
---
-It is a rough equivalent for:
-------
-	$ git reset --soft HEAD^
-	$ ... do something else to come up with the right tree ...
-	$ git commit -c ORIG_HEAD
-
-------
-but can be used to amend a merge commit.
---
-
--i|--include::
-	Before making a commit out of staged contents so far,
-	stage the contents of paths given on the command line
-	as well.  This is usually not what you want unless you
-	are concluding a conflicted merge.
-
--u|--untracked-files::
-	Show all untracked files, also those in uninteresting
-	directories, in the "Untracked files:" section of commit
-	message template.  Without this option only its name and
-	a trailing slash are displayed for each untracked
-	directory.
-
--v|--verbose::
-	Show unified diff between the HEAD commit and what
-	would be committed at the bottom of the commit message
-	template.  Note that this diff output doesn't have its
-	lines prefixed with '#'.
-
--q|--quiet::
-	Suppress commit summary message.
-
-\--::
-	Do not interpret any more arguments as options.
-
-<file>...::
-	When files are given on the command line, the command
-	commits the contents of the named files, without
-	recording the changes already staged.  The contents of
-	these files are also staged for the next commit on top
-	of what have been staged before.
-
-
-EXAMPLES
---------
-When recording your own work, the contents of modified files in
-your working tree are temporarily stored to a staging area
-called the "index" with linkgit:git-add[1].  A file can be
-reverted back, only in the index but not in the working tree,
-to that of the last commit with `git-reset HEAD -- <file>`,
-which effectively reverts `git-add` and prevents the changes to
-this file from participating in the next commit.  After building
-the state to be committed incrementally with these commands,
-`git commit` (without any pathname parameter) is used to record what
-has been staged so far.  This is the most basic form of the
-command.  An example:
-
-------------
-$ edit hello.c
-$ git rm goodbye.c
-$ git add hello.c
-$ git commit
-------------
-
-Instead of staging files after each individual change, you can
-tell `git commit` to notice the changes to the files whose
-contents are tracked in
-your working tree and do corresponding `git add` and `git rm`
-for you.  That is, this example does the same as the earlier
-example if there is no other change in your working tree:
-
-------------
-$ edit hello.c
-$ rm goodbye.c
-$ git commit -a
-------------
-
-The command `git commit -a` first looks at your working tree,
-notices that you have modified hello.c and removed goodbye.c,
-and performs necessary `git add` and `git rm` for you.
-
-After staging changes to many files, you can alter the order the
-changes are recorded in, by giving pathnames to `git commit`.
-When pathnames are given, the command makes a commit that
-only records the changes made to the named paths:
-
-------------
-$ edit hello.c hello.h
-$ git add hello.c hello.h
-$ edit Makefile
-$ git commit Makefile
-------------
-
-This makes a commit that records the modification to `Makefile`.
-The changes staged for `hello.c` and `hello.h` are not included
-in the resulting commit.  However, their changes are not lost --
-they are still staged and merely held back.  After the above
-sequence, if you do:
-
-------------
-$ git commit
-------------
-
-this second commit would record the changes to `hello.c` and
-`hello.h` as expected.
-
-After a merge (initiated by either linkgit:git-merge[1] or
-linkgit:git-pull[1]) stops because of conflicts, cleanly merged
-paths are already staged to be committed for you, and paths that
-conflicted are left in unmerged state.  You would have to first
-check which paths are conflicting with linkgit:git-status[1]
-and after fixing them manually in your working tree, you would
-stage the result as usual with linkgit:git-add[1]:
-
-------------
-$ git status | grep unmerged
-unmerged: hello.c
-$ edit hello.c
-$ git add hello.c
-------------
-
-After resolving conflicts and staging the result, `git ls-files -u`
-would stop mentioning the conflicted path.  When you are done,
-run `git commit` to finally record the merge:
-
-------------
-$ git commit
-------------
-
-As with the case to record your own changes, you can use `-a`
-option to save typing.  One difference is that during a merge
-resolution, you cannot use `git commit` with pathnames to
-alter the order the changes are committed, because the merge
-should be recorded as a single commit.  In fact, the command
-refuses to run when given pathnames (but see `-i` option).
-
-
-DISCUSSION
-----------
-
-Though not required, it's a good idea to begin the commit message
-with a single short (less than 50 character) line summarizing the
-change, followed by a blank line and then a more thorough description.
-Tools that turn commits into email, for example, use the first line
-on the Subject: line and the rest of the commit in the body.
-
-include::i18n.txt[]
-
-ENVIRONMENT AND CONFIGURATION VARIABLES
----------------------------------------
-The editor used to edit the commit log message will be chosen from the
-GIT_EDITOR environment variable, the core.editor configuration variable, the
-VISUAL environment variable, or the EDITOR environment variable (in that
-order).
-
-HOOKS
------
-This command can run `commit-msg`, `pre-commit`, and
-`post-commit` hooks.  See link:hooks.html[hooks] for more
-information.
-
-
-SEE ALSO
---------
-linkgit:git-add[1],
-linkgit:git-rm[1],
-linkgit:git-mv[1],
-linkgit:git-merge[1],
-linkgit:git-commit-tree[1]
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org> and
-Junio C Hamano <junkio@cox.net>
-
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-config.txt

@@ -1,335 +0,0 @@
-git-config(1)
-=============
-
-NAME
-----
-git-config - Get and set repository or global options
-
-
-SYNOPSIS
---------
-[verse]
-'git-config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
-'git-config' [<file-option>] [type] --add name value
-'git-config' [<file-option>] [type] --replace-all name [value [value_regex]]
-'git-config' [<file-option>] [type] [-z|--null] --get name [value_regex]
-'git-config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
-'git-config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
-'git-config' [<file-option>] --unset name [value_regex]
-'git-config' [<file-option>] --unset-all name [value_regex]
-'git-config' [<file-option>] --rename-section old_name new_name
-'git-config' [<file-option>] --remove-section name
-'git-config' [<file-option>] [-z|--null] -l | --list
-'git-config' [<file-option>] --get-color name [default]
-'git-config' [<file-option>] --get-colorbool name [stdout-is-tty]
-
-DESCRIPTION
------------
-You can query/set/replace/unset options with this command. The name is
-actually the section and the key separated by a dot, and the value will be
-escaped.
-
-Multiple lines can be added to an option by using the '--add' option.
-If you want to update or unset an option which can occur on multiple
-lines, a POSIX regexp `value_regex` needs to be given.  Only the
-existing values that match the regexp are updated or unset.  If
-you want to handle the lines that do *not* match the regex, just
-prepend a single exclamation mark in front (see also <<EXAMPLES>>).
-
-The type specifier can be either '--int' or '--bool', which will make
-'git-config' ensure that the variable(s) are of the given type and
-convert the value to the canonical form (simple decimal number for int,
-a "true" or "false" string for bool).  If no type specifier is passed,
-no checks or transformations are performed on the value.
-
-The file-option can be one of '--system', '--global' or '--file'
-which specify where the values will be read from or written to.
-The default is to assume the config file of the current repository,
-.git/config unless defined otherwise with GIT_DIR and GIT_CONFIG
-(see <<FILES>>).
-
-This command will fail if:
-
-. The config file is invalid,
-. Can not write to the config file,
-. no section was provided,
-. the section or key is invalid,
-. you try to unset an option which does not exist,
-. you try to unset/set an option for which multiple lines match, or
-. you use '--global' option without $HOME being properly set.
-
-
-OPTIONS
--------
-
---replace-all::
-	Default behavior is to replace at most one line. This replaces
-	all lines matching the key (and optionally the value_regex).
-
---add::
-	Adds a new line to the option without altering any existing
-	values.  This is the same as providing '^$' as the value_regex.
-
---get::
-	Get the value for a given key (optionally filtered by a regex
-	matching the value). Returns error code 1 if the key was not
-	found and error code 2 if multiple key values were found.
-
---get-all::
-	Like get, but does not fail if the number of values for the key
-	is not exactly one.
-
---get-regexp::
-	Like --get-all, but interprets the name as a regular expression.
-	Also outputs the key names.
-
---global::
-	For writing options: write to global ~/.gitconfig file rather than
-	the repository .git/config.
-+
-For reading options: read only from global ~/.gitconfig rather than
-from all available files.
-+
-See also <<FILES>>.
-
---system::
-	For writing options: write to system-wide $(prefix)/etc/gitconfig
-	rather than the repository .git/config.
-+
-For reading options: read only from system-wide $(prefix)/etc/gitconfig
-rather than from all available files.
-+
-See also <<FILES>>.
-
--f config-file, --file config-file::
-	Use the given config file instead of the one specified by GIT_CONFIG.
-
---remove-section::
-	Remove the given section from the configuration file.
-
---rename-section::
-	Rename the given section to a new name.
-
---unset::
-	Remove the line matching the key from config file.
-
---unset-all::
-	Remove all lines matching the key from config file.
-
--l, --list::
-	List all variables set in config file.
-
---bool::
-	git-config will ensure that the output is "true" or "false"
-
---int::
-	git-config will ensure that the output is a simple
-	decimal number.  An optional value suffix of 'k', 'm', or 'g'
-	in the config file will cause the value to be multiplied
-	by 1024, 1048576, or 1073741824 prior to output.
-
--z, --null::
-	For all options that output values and/or keys, always
-	end values with the null character (instead of a
-	newline). Use newline instead as a delimiter between
-	key and value. This allows for secure parsing of the
-	output without getting confused e.g. by values that
-	contain line breaks.
-
---get-colorbool name [stdout-is-tty]::
-
-	Find the color setting for `name` (e.g. `color.diff`) and output
-	"true" or "false".  `stdout-is-tty` should be either "true" or
-	"false", and is taken into account when configuration says
-	"auto".  If `stdout-is-tty` is missing, then checks the standard
-	output of the command itself, and exits with status 0 if color
-	is to be used, or exits with status 1 otherwise.
-
---get-color name default::
-
-	Find the color configured for `name` (e.g. `color.diff.new`) and
-	output it as the ANSI color escape sequence to the standard
-	output.  The optional `default` parameter is used instead, if
-	there is no color configured for `name`.
-
-[[FILES]]
-FILES
------
-
-If not set explicitly with '--file', there are three files where
-git-config will search for configuration options:
-
-$GIT_DIR/config::
-	Repository specific configuration file. (The filename is
-	of course relative to the repository root, not the working
-	directory.)
-
-~/.gitconfig::
-	User-specific configuration file. Also called "global"
-	configuration file.
-
-$(prefix)/etc/gitconfig::
-	System-wide configuration file.
-
-If no further options are given, all reading options will read all of these
-files that are available. If the global or the system-wide configuration
-file are not available they will be ignored. If the repository configuration
-file is not available or readable, git-config will exit with a non-zero
-error code. However, in neither case will an error message be issued.
-
-All writing options will per default write to the repository specific
-configuration file. Note that this also affects options like '--replace-all'
-and '--unset'. *git-config will only ever change one file at a time*.
-
-You can override these rules either by command line options or by environment
-variables. The '--global' and the '--system' options will limit the file used
-to the global or system-wide file respectively. The GIT_CONFIG environment
-variable has a similar effect, but you can specify any filename you want.
-
-The GIT_CONFIG_LOCAL environment variable on the other hand only changes
-the name used instead of the repository configuration file. The global and
-the system-wide configuration files will still be read. (For writing options
-this will obviously result in the same behavior as using GIT_CONFIG.)
-
-
-ENVIRONMENT
------------
-
-GIT_CONFIG::
-	Take the configuration from the given file instead of .git/config.
-	Using the "--global" option forces this to ~/.gitconfig. Using the
-	"--system" option forces this to $(prefix)/etc/gitconfig.
-
-GIT_CONFIG_LOCAL::
-	Take the configuration from the given file instead if .git/config.
-	Still read the global and the system-wide configuration files, though.
-
-See also <<FILES>>.
-
-
-[[EXAMPLES]]
-EXAMPLES
---------
-
-Given a .git/config like this:
-
-	#
-	# This is the config file, and
-	# a '#' or ';' character indicates
-	# a comment
-	#
-
-	; core variables
-	[core]
-		; Don't trust file modes
-		filemode = false
-
-	; Our diff algorithm
-	[diff]
-		external = "/usr/local/bin/gnu-diff -u"
-		renames = true
-
-	; Proxy settings
-	[core]
-		gitproxy="proxy-command" for kernel.org
-		gitproxy=default-proxy ; for all the rest
-
-you can set the filemode to true with
-
-------------
-% git config core.filemode true
-------------
-
-The hypothetical proxy command entries actually have a postfix to discern
-what URL they apply to. Here is how to change the entry for kernel.org
-to "ssh".
-
-------------
-% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
-------------
-
-This makes sure that only the key/value pair for kernel.org is replaced.
-
-To delete the entry for renames, do
-
-------------
-% git config --unset diff.renames
-------------
-
-If you want to delete an entry for a multivar (like core.gitproxy above),
-you have to provide a regex matching the value of exactly one line.
-
-To query the value for a given key, do
-
-------------
-% git config --get core.filemode
-------------
-
-or
-
-------------
-% git config core.filemode
-------------
-
-or, to query a multivar:
-
-------------
-% git config --get core.gitproxy "for kernel.org$"
-------------
-
-If you want to know all the values for a multivar, do:
-
-------------
-% git config --get-all core.gitproxy
-------------
-
-If you like to live dangerous, you can replace *all* core.gitproxy by a
-new one with
-
-------------
-% git config --replace-all core.gitproxy ssh
-------------
-
-However, if you really only want to replace the line for the default proxy,
-i.e. the one without a "for ..." postfix, do something like this:
-
-------------
-% git config core.gitproxy ssh '! for '
-------------
-
-To actually match only values with an exclamation mark, you have to
-
-------------
-% git config section.key value '[!]'
-------------
-
-To add a new proxy, without altering any of the existing ones, use
-
-------------
-% git config core.gitproxy '"proxy-command" for example.com'
-------------
-
-An example to use customized color from the configuration in your
-script:
-
-------------
-#!/bin/sh
-WS=$(git config --get-color color.diff.whitespace "blue reverse")
-RESET=$(git config --get-color "" "reset")
-echo "${WS}your whitespace color or blue reverse${RESET}"
-------------
-
-include::config.txt[]
-
-
-Author
-------
-Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
-
-Documentation
---------------
-Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-count-objects.txt

@@ -1,37 +0,0 @@
-git-count-objects(1)
-====================
-
-NAME
-----
-git-count-objects - Count unpacked number of objects and their disk consumption
-
-SYNOPSIS
---------
-'git-count-objects' [-v]
-
-DESCRIPTION
------------
-This counts the number of unpacked object files and disk space consumed by
-them, to help you decide when it is a good time to repack.
-
-
-OPTIONS
--------
--v::
-	In addition to the number of loose objects and disk
-	space consumed, it reports the number of in-pack
-	objects, number of packs, and number of objects that can be
-	removed by running `git-prune-packed`.
-
-
-Author
-------
-Written by Junio C Hamano <junkio@cox.net>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-cvsexportcommit.txt

@@ -1,109 +0,0 @@
-git-cvsexportcommit(1)
-======================
-
-NAME
-----
-git-cvsexportcommit - Export a single commit to a CVS checkout
-
-
-SYNOPSIS
---------
-'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
-
-
-DESCRIPTION
------------
-Exports a commit from GIT to a CVS checkout, making it easier
-to merge patches from a git repository into a CVS repository.
-
-Specify the name of a CVS checkout using the -w switch or execute it
-from the root of the CVS working copy. In the latter case GIT_DIR must
-be defined. See examples below.
-
-It does its best to do the safe thing, it will check that the files are
-unchanged and up to date in the CVS checkout, and it will not autocommit
-by default.
-
-Supports file additions, removals, and commits that affect binary files.
-
-If the commit is a merge commit, you must tell git-cvsexportcommit what parent
-should the changeset be done against.
-
-OPTIONS
--------
-
--c::
-	Commit automatically if the patch applied cleanly. It will not
-	commit if any hunks fail to apply or there were other problems.
-
--p::
-	Be pedantic (paranoid) when applying patches. Invokes patch with
-	--fuzz=0
-
--a::
-	Add authorship information. Adds Author line, and Committer (if
-	different from Author) to the message.
-
--d::
-	Set an alternative CVSROOT to use.  This corresponds to the CVS
-	-d parameter.  Usually users will not want to set this, except
-	if using CVS in an asymmetric fashion.
-
--f::
-	Force the merge even if the files are not up to date.
-
--P::
-	Force the parent commit, even if it is not a direct parent.
-
--m::
-	Prepend the commit message with the provided prefix.
-	Useful for patch series and the like.
-
--u::
-	Update affected files from CVS repository before attempting export.
-
--w::
-	Specify the location of the CVS checkout to use for the export. This
-	option does not require GIT_DIR to be set before execution if the
-	current directory is within a git repository.
-
--v::
-	Verbose.
-
-EXAMPLES
---------
-
-Merge one patch into CVS::
-+
-------------
-$ export GIT_DIR=~/project/.git
-$ cd ~/project_cvs_checkout
-$ git-cvsexportcommit -v <commit-sha1>
-$ cvs commit -F .msg <files>
-------------
-
-Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
-+
-------------
-	$ git-cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
-------------
-
-Merge pending patches into CVS automatically -- only if you really know what you are doing::
-+
-------------
-$ export GIT_DIR=~/project/.git
-$ cd ~/project_cvs_checkout
-$ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit -c -p -v
-------------
-
-Author
-------
-Written by Martin Langhoff <martin@catalyst.net.nz> and others.
-
-Documentation
---------------
-Documentation by Martin Langhoff <martin@catalyst.net.nz> and others.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-cvsimport.txt

@@ -1,169 +0,0 @@
-git-cvsimport(1)
-================
-
-NAME
-----
-git-cvsimport - Salvage your data out of another SCM people love to hate
-
-
-SYNOPSIS
---------
-[verse]
-'git-cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
-	      [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
-	      [-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
-	      [-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
-	      [-r <remote>] [<CVS_module>]
-
-
-DESCRIPTION
------------
-Imports a CVS repository into git. It will either create a new
-repository, or incrementally import into an existing one.
-
-Splitting the CVS log into patch sets is done by 'cvsps'.
-At least version 2.1 is required.
-
-You should *never* do any work of your own on the branches that are
-created by git-cvsimport.  By default initial import will create and populate a
-"master" branch from the CVS repository's main branch which you're free
-to work with; after that, you need to 'git merge' incremental imports, or
-any CVS branches, yourself.  It is advisable to specify a named remote via
--r to separate and protect the incoming branches.
-
-
-OPTIONS
--------
--v::
-	Verbosity: let 'cvsimport' report what it is doing.
-
--d <CVSROOT>::
-	The root of the CVS archive. May be local (a simple path) or remote;
-	currently, only the :local:, :ext: and :pserver: access methods
-	are supported. If not given, git-cvsimport will try to read it
-	from `CVS/Root`. If no such file exists, it checks for the
-	`CVSROOT` environment variable.
-
-<CVS_module>::
-	The CVS module you want to import. Relative to <CVSROOT>.
-	If not given, git-cvsimport tries to read it from
-	`CVS/Repository`.
-
--C <target-dir>::
-        The git repository to import to.  If the directory doesn't
-        exist, it will be created.  Default is the current directory.
-
--r <remote>::
-	The git remote to import this CVS repository into.
-	Moves all CVS branches into remotes/<remote>/<branch>
-	akin to the git-clone --use-separate-remote option.
-
--o <branch-for-HEAD>::
-	When no remote is specified (via -r) the 'HEAD' branch
-	from CVS is imported to the 'origin' branch within the git
-	repository, as 'HEAD' already has a special meaning for git.
-	When a remote is specified the 'HEAD' branch is named
-	remotes/<remote>/master mirroring git-clone behaviour.
-	Use this option if you want to import into a different
-	branch.
-+
-Use '-o master' for continuing an import that was initially done by
-the old cvs2git tool.
-
--i::
-	Import-only: don't perform a checkout after importing.  This option
-	ensures the working directory and index remain untouched and will
-	not create them if they do not exist.
-
--k::
-	Kill keywords: will extract files with '-kk' from the CVS archive
-	to avoid noisy changesets. Highly recommended, but off by default
-	to preserve compatibility with early imported trees.
-
--u::
-	Convert underscores in tag and branch names to dots.
-
--s <subst>::
-	Substitute the character "/" in branch names with <subst>
-
--p <options-for-cvsps>::
-	Additional options for cvsps.
-	The options '-u' and '-A' are implicit and should not be used here.
-+
-If you need to pass multiple options, separate them with a comma.
-
--z <fuzz>::
-	Pass the timestamp fuzz factor to cvsps, in seconds. If unset,
-	cvsps defaults to 300s.
-
--P <cvsps-output-file>::
-	Instead of calling cvsps, read the provided cvsps output file. Useful
-	for debugging or when cvsps is being handled outside cvsimport.
-
--m::
-	Attempt to detect merges based on the commit message. This option
-	will enable default regexes that try to capture the name source
-	branch name from the commit message.
-
--M <regex>::
-	Attempt to detect merges based on the commit message with a custom
-	regex. It can be used with '-m' to enable the default regexes
-	as well. You must escape forward slashes.
-
--S <regex>::
-	Skip paths matching the regex.
-
--a::
-	Import all commits, including recent ones. cvsimport by default
-	skips commits that have a timestamp less than 10 minutes ago.
-
--L <limit>::
-	Limit the number of commits imported. Workaround for cases where
-	cvsimport leaks memory.
-
--A <author-conv-file>::
-	CVS by default uses the Unix username when writing its
-	commit logs. Using this option and an author-conv-file
-	in this format
-+
----------
-	exon=Andreas Ericsson <ae@op5.se>
-	spawn=Simon Pawn <spawn@frog-pond.org>
-
----------
-+
-git-cvsimport will make it appear as those authors had
-their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
-all along.
-+
-For convenience, this data is saved to `$GIT_DIR/cvs-authors`
-each time the '-A' option is provided and read from that same
-file each time git-cvsimport is run.
-+
-It is not recommended to use this feature if you intend to
-export changes back to CVS again later with
-linkgit:git-cvsexportcommit[1].
-
--h::
-	Print a short usage message and exit.
-
-OUTPUT
-------
-If '-v' is specified, the script reports what it is doing.
-
-Otherwise, success is indicated the Unix way, i.e. by simply exiting with
-a zero exit status.
-
-
-Author
-------
-Written by Matthias Urlichs <smurf@smurf.noris.de>, with help from
-various participants of the git-list <git@vger.kernel.org>.
-
-Documentation
---------------
-Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-cvsserver.txt

@@ -1,322 +0,0 @@
-git-cvsserver(1)
-================
-
-NAME
-----
-git-cvsserver - A CVS server emulator for git
-
-SYNOPSIS
---------
-
-SSH:
-
-[verse]
-export CVS_SERVER=git-cvsserver
-'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
-
-pserver (/etc/inetd.conf):
-
-[verse]
-cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
-
-Usage:
-
-[verse]
-'git-cvsserver' [options] [pserver|server] [<directory> ...]
-
-OPTIONS
--------
-
-All these options obviously only make sense if enforced by the server side.
-They have been implemented to resemble the linkgit:git-daemon[1] options as
-closely as possible.
-
---base-path <path>::
-Prepend 'path' to requested CVSROOT
-
---strict-paths::
-Don't allow recursing into subdirectories
-
---export-all::
-Don't check for `gitcvs.enabled` in config. You also have to specify a list
-of allowed directories (see below) if you want to use this option.
-
---version, -V::
-Print version information and exit
-
---help, -h, -H::
-Print usage information and exit
-
-<directory>::
-You can specify a list of allowed directories. If no directories
-are given, all are allowed. This is an additional restriction, gitcvs
-access still needs to be enabled by the `gitcvs.enabled` config option
-unless '--export-all' was given, too.
-
-
-DESCRIPTION
------------
-
-This application is a CVS emulation layer for git.
-
-It is highly functional. However, not all methods are implemented,
-and for those methods that are implemented,
-not all switches are implemented.
-
-Testing has been done using both the CLI CVS client, and the Eclipse CVS
-plugin. Most functionality works fine with both of these clients.
-
-LIMITATIONS
------------
-
-Currently cvsserver works over SSH connections for read/write clients, and
-over pserver for anonymous CVS access.
-
-CVS clients cannot tag, branch or perform GIT merges.
-
-git-cvsserver maps GIT branches to CVS modules. This is very different
-from what most CVS users would expect since in CVS modules usually represent
-one or more directories.
-
-INSTALLATION
-------------
-
-1. If you are going to offer anonymous CVS access via pserver, add a line in
-   /etc/inetd.conf like
-+
---
-------
-   cvspserver stream tcp nowait nobody git-cvsserver pserver
-
-------
-Note: Some inetd servers let you specify the name of the executable
-independently of the value of argv[0] (i.e. the name the program assumes
-it was executed with). In this case the correct line in /etc/inetd.conf
-looks like
-
-------
-   cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
-
-------
-No special setup is needed for SSH access, other than having GIT tools
-in the PATH. If you have clients that do not accept the CVS_SERVER
-environment variable, you can rename git-cvsserver to cvs.
-
-Note: Newer CVS versions (>= 1.12.11) also support specifying
-CVS_SERVER directly in CVSROOT like
-
-------
-cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co <HEAD_name>
-------
-This has the advantage that it will be saved in your 'CVS/Root' files and
-you don't need to worry about always setting the correct environment
-variable.
---
-2. For each repo that you want accessible from CVS you need to edit config in
-   the repo and add the following section.
-+
---
-------
-   [gitcvs]
-        enabled=1
-        # optional for debugging
-        logfile=/path/to/logfile
-
-------
-Note: you need to ensure each user that is going to invoke git-cvsserver has
-write access to the log file and to the database (see
-<<dbbackend,Database Backend>>. If you want to offer write access over
-SSH, the users of course also need write access to the git repository itself.
-
-[[configaccessmethod]]
-All configuration variables can also be overridden for a specific method of
-access. Valid method names are "ext" (for SSH access) and "pserver". The
-following example configuration would disable pserver access while still
-allowing access over SSH.
-------
-   [gitcvs]
-        enabled=0
-
-   [gitcvs "ext"]
-        enabled=1
-------
---
-3. On the client machine you need to set the following variables.
-   CVSROOT should be set as per normal, but the directory should point at the
-   appropriate git repo. For example:
-+
---
-For SSH access, CVS_SERVER should be set to git-cvsserver
-
-Example:
-
-------
-     export CVSROOT=:ext:user@server:/var/git/project.git
-     export CVS_SERVER=git-cvsserver
-------
---
-4. For SSH clients that will make commits, make sure their .bashrc file
-   sets the GIT_AUTHOR and GIT_COMMITTER variables.
-
-5. Clients should now be able to check out the project. Use the CVS 'module'
-   name to indicate what GIT 'head' you want to check out. Example:
-+
-------
-     cvs co -d project-master master
-------
-
-[[dbbackend]]
-Database Backend
-----------------
-
-git-cvsserver uses one database per git head (i.e. CVS module) to
-store information about the repository for faster access. The
-database doesn't contain any persistent data and can be completely
-regenerated from the git repository at any time. The database
-needs to be updated (i.e. written to) after every commit.
-
-If the commit is done directly by using git (as opposed to
-using git-cvsserver) the update will need to happen on the
-next repository access by git-cvsserver, independent of
-access method and requested operation.
-
-That means that even if you offer only read access (e.g. by using
-the pserver method), git-cvsserver should have write access to
-the database to work reliably (otherwise you need to make sure
-that the database is up-to-date any time git-cvsserver is executed).
-
-By default it uses SQLite databases in the git directory, named
-`gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates
-temporary files in the same directory as the database file on
-write so it might not be enough to grant the users using
-git-cvsserver write access to the database file without granting
-them write access to the directory, too.
-
-You can configure the database backend with the following
-configuration variables:
-
-Configuring database backend
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-git-cvsserver uses the Perl DBI module. Please also read
-its documentation if changing these variables, especially
-about `DBI->connect()`.
-
-gitcvs.dbname::
-	Database name. The exact meaning depends on the
-	selected database driver, for SQLite this is a filename.
-	Supports variable substitution (see below). May
-	not contain semicolons (`;`).
-	Default: '%Ggitcvs.%m.sqlite'
-
-gitcvs.dbdriver::
-	Used DBI driver. You can specify any available driver
-	for this here, but it might not work. cvsserver is tested
-	with 'DBD::SQLite', reported to work with
-	'DBD::Pg', and reported *not* to work with 'DBD::mysql'.
-	Please regard this as an experimental feature. May not
-	contain colons (`:`).
-	Default: 'SQLite'
-
-gitcvs.dbuser::
-	Database user. Only useful if setting `dbdriver`, since
-	SQLite has no concept of database users. Supports variable
-	substitution (see below).
-
-gitcvs.dbpass::
-	Database password.  Only useful if setting `dbdriver`, since
-	SQLite has no concept of database passwords.
-
-All variables can also be set per access method, see <<configaccessmethod,above>>.
-
-Variable substitution
-^^^^^^^^^^^^^^^^^^^^^
-In `dbdriver` and `dbuser` you can use the following variables:
-
-%G::
-	git directory name
-%g::
-	git directory name, where all characters except for
-	alpha-numeric ones, `.`, and `-` are replaced with
-	`_` (this should make it easier to use the directory
-	name in a filename if wanted)
-%m::
-	CVS module/git head name
-%a::
-	access method (one of "ext" or "pserver")
-%u::
-	Name of the user running git-cvsserver.
-	If no name can be determined, the
-	numeric uid is used.
-
-Eclipse CVS Client Notes
-------------------------
-
-To get a checkout with the Eclipse CVS client:
-
-1. Select "Create a new project -> From CVS checkout"
-2. Create a new location. See the notes below for details on how to choose the
-   right protocol.
-3. Browse the 'modules' available. It will give you a list of the heads in
-   the repository. You will not be able to browse the tree from there. Only
-   the heads.
-4. Pick 'HEAD' when it asks what branch/tag to check out. Untick the
-   "launch commit wizard" to avoid committing the .project file.
-
-Protocol notes: If you are using anonymous access via pserver, just select that.
-Those using SSH access should choose the 'ext' protocol, and configure 'ext'
-access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
-'git-cvsserver'. Note that password support is not good when using 'ext',
-you will definitely want to have SSH keys setup.
-
-Alternatively, you can just use the non-standard extssh protocol that Eclipse
-offer. In that case CVS_SERVER is ignored, and you will have to replace
-the cvs utility on the server with git-cvsserver or manipulate your `.bashrc`
-so that calling 'cvs' effectively calls git-cvsserver.
-
-Clients known to work
----------------------
-
-- CVS 1.12.9 on Debian
-- CVS 1.11.17 on MacOSX (from Fink package)
-- Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
-- TortoiseCVS
-
-Operations supported
---------------------
-
-All the operations required for normal use are supported, including
-checkout, diff, status, update, log, add, remove, commit.
-Legacy monitoring operations are not supported (edit, watch and related).
-Exports and tagging (tags and branches) are not supported at this stage.
-
-The server should set the '-k' mode to binary when relevant, however,
-this is not really implemented yet. For now, you can force the server
-to set '-kb' for all files by setting the `gitcvs.allbinary` config
-variable. In proper GIT tradition, the contents of the files are
-always respected. No keyword expansion or newline munging is supported.
-
-Dependencies
-------------
-
-git-cvsserver depends on DBD::SQLite.
-
-Copyright and Authors
----------------------
-
-This program is copyright The Open University UK - 2006.
-
-Authors:
-
-- Martyn Smith    <martyn@catalyst.net.nz>
-- Martin Langhoff <martin@catalyst.net.nz>
-
-with ideas and patches from participants of the git-list <git@vger.kernel.org>.
-
-Documentation
---------------
-Documentation by Martyn Smith <martyn@catalyst.net.nz>, Martin Langhoff <martin@catalyst.net.nz>, and Matthias Urlichs <smurf@smurf.noris.de>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-daemon.txt

@@ -1,275 +0,0 @@
-git-daemon(1)
-=============
-
-NAME
-----
-git-daemon - A really simple server for git repositories
-
-SYNOPSIS
---------
-[verse]
-'git-daemon' [--verbose] [--syslog] [--export-all]
-             [--timeout=n] [--init-timeout=n] [--strict-paths]
-             [--base-path=path] [--user-path | --user-path=path]
-             [--interpolated-path=pathtemplate]
-             [--reuseaddr] [--detach] [--pid-file=file]
-             [--enable=service] [--disable=service]
-	     [--allow-override=service] [--forbid-override=service]
-	     [--inetd | [--listen=host_or_ipaddr] [--port=n] [--user=user [--group=group]]
-	     [directory...]
-
-DESCRIPTION
------------
-A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT"
-aka 9418.  It waits for a connection asking for a service, and will serve
-that service if it is enabled.
-
-It verifies that the directory has the magic file "git-daemon-export-ok", and
-it will refuse to export any git directory that hasn't explicitly been marked
-for export this way (unless the '--export-all' parameter is specified). If you
-pass some directory paths as 'git-daemon' arguments, you can further restrict
-the offers to a whitelist comprising of those.
-
-By default, only `upload-pack` service is enabled, which serves
-`git-fetch-pack` and `git-ls-remote` clients, which are invoked
-from `git-fetch`, `git-pull`, and `git-clone`.
-
-This is ideally suited for read-only updates, i.e., pulling from
-git repositories.
-
-An `upload-archive` also exists to serve `git-archive`.
-
-OPTIONS
--------
---strict-paths::
-	Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
-	"/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
-	git-daemon will refuse to start when this option is enabled and no
-	whitelist is specified.
-
---base-path::
-	Remap all the path requests as relative to the given path.
-	This is sort of "GIT root" - if you run git-daemon with
-	'--base-path=/srv/git' on example.com, then if you later try to pull
-	'git://example.com/hello.git', `git-daemon` will interpret the path
-	as '/srv/git/hello.git'.
-
---base-path-relaxed::
-	If --base-path is enabled and repo lookup fails, with this option
-	`git-daemon` will attempt to lookup without prefixing the base path.
-	This is useful for switching to --base-path usage, while still
-	allowing the old paths.
-
---interpolated-path=pathtemplate::
-	To support virtual hosting, an interpolated path template can be
-	used to dynamically construct alternate paths.  The template
-	supports %H for the target hostname as supplied by the client but
-	converted to all lowercase, %CH for the canonical hostname,
-	%IP for the server's IP address, %P for the port number,
-	and %D for the absolute path of the named repository.
-	After interpolation, the path is validated against the directory
-	whitelist.
-
---export-all::
-	Allow pulling from all directories that look like GIT repositories
-	(have the 'objects' and 'refs' subdirectories), even if they
-	do not have the 'git-daemon-export-ok' file.
-
---inetd::
-	Have the server run as an inetd service. Implies --syslog.
-	Incompatible with --port, --listen, --user and --group options.
-
---listen=host_or_ipaddr::
-	Listen on an a specific IP address or hostname.  IP addresses can
-	be either an IPv4 address or an IPV6 address if supported.  If IPv6
-	is not supported, then --listen=hostname is also not supported and
-	--listen must be given an IPv4 address.
-	Incompatible with '--inetd' option.
-
---port=n::
-	Listen on an alternative port.  Incompatible with '--inetd' option.
-
---init-timeout::
-	Timeout between the moment the connection is established and the
-	client request is received (typically a rather low value, since
-	that should be basically immediate).
-
---timeout::
-	Timeout for specific client sub-requests. This includes the time
-	it takes for the server to process the sub-request and time spent
-	waiting for next client's request.
-
---syslog::
-	Log to syslog instead of stderr. Note that this option does not imply
-	--verbose, thus by default only error conditions will be logged.
-
---user-path, --user-path=path::
-	Allow ~user notation to be used in requests.  When
-	specified with no parameter, requests to
-	git://host/~alice/foo is taken as a request to access
-	'foo' repository in the home directory of user `alice`.
-	If `--user-path=path` is specified, the same request is
-	taken as a request to access `path/foo` repository in
-	the home directory of user `alice`.
-
---verbose::
-	Log details about the incoming connections and requested files.
-
---reuseaddr::
-	Use SO_REUSEADDR when binding the listening socket.
-	This allows the server to restart without waiting for
-	old connections to time out.
-
---detach::
-	Detach from the shell. Implies --syslog.
-
---pid-file=file::
-	Save the process id in 'file'.  Ignored when the daemon
-	is run under `--inetd`.
-
---user=user, --group=group::
-	Change daemon's uid and gid before entering the service loop.
-	When only `--user` is given without `--group`, the
-	primary group ID for the user is used.  The values of
-	the option are given to `getpwnam(3)` and `getgrnam(3)`
-	and numeric IDs are not supported.
-+
-Giving these options is an error when used with `--inetd`; use
-the facility of inet daemon to achieve the same before spawning
-`git-daemon` if needed.
-
---enable=service, --disable=service::
-	Enable/disable the service site-wide per default.  Note
-	that a service disabled site-wide can still be enabled
-	per repository if it is marked overridable and the
-	repository enables the service with an configuration
-	item.
-
---allow-override=service, --forbid-override=service::
-	Allow/forbid overriding the site-wide default with per
-	repository configuration.  By default, all the services
-	are overridable.
-
-<directory>::
-	A directory to add to the whitelist of allowed directories. Unless
-	--strict-paths is specified this will also include subdirectories
-	of each named directory.
-
-SERVICES
---------
-
-These services can be globally enabled/disabled using the
-command line options of this command.  If a finer-grained
-control is desired (e.g. to allow `git-archive` to be run
-against only in a few selected repositories the daemon serves),
-the per-repository configuration file can be used to enable or
-disable them.
-
-upload-pack::
-	This serves `git-fetch-pack` and `git-ls-remote`
-	clients.  It is enabled by default, but a repository can
-	disable it by setting `daemon.uploadpack` configuration
-	item to `false`.
-
-upload-archive::
-	This serves `git-archive --remote`.  It is disabled by
-	default, but a repository can enable it by setting
-	`daemon.uploadarchive` configuration item to `true`.
-
-receive-pack::
-	This serves `git-send-pack` clients, allowing anonymous
-	push.  It is disabled by default, as there is _no_
-	authentication in the protocol (in other words, anybody
-	can push anything into the repository, including removal
-	of refs).  This is solely meant for a closed LAN setting
-	where everybody is friendly.  This service can be
-	enabled by `daemon.receivepack` configuration item to
-	`true`.
-
-EXAMPLES
---------
-We assume the following in /etc/services::
-+
-------------
-$ grep 9418 /etc/services
-git		9418/tcp		# Git Version Control System
-------------
-
-git-daemon as inetd server::
-	To set up `git-daemon` as an inetd service that handles any
-	repository under the whitelisted set of directories, /pub/foo
-	and /pub/bar, place an entry like the following into
-	/etc/inetd all on one line:
-+
-------------------------------------------------
-	git stream tcp nowait nobody  /usr/bin/git-daemon
-		git-daemon --inetd --verbose --export-all
-		/pub/foo /pub/bar
-------------------------------------------------
-
-
-git-daemon as inetd server for virtual hosts::
-	To set up `git-daemon` as an inetd service that handles
-	repositories for different virtual hosts, `www.example.com`
-	and `www.example.org`, place an entry like the following into
-	`/etc/inetd` all on one line:
-+
-------------------------------------------------
-	git stream tcp nowait nobody /usr/bin/git-daemon
-		git-daemon --inetd --verbose --export-all
-		--interpolated-path=/pub/%H%D
-		/pub/www.example.org/software
-		/pub/www.example.com/software
-		/software
-------------------------------------------------
-+
-In this example, the root-level directory `/pub` will contain
-a subdirectory for each virtual host name supported.
-Further, both hosts advertise repositories simply as
-`git://www.example.com/software/repo.git`.  For pre-1.4.0
-clients, a symlink from `/software` into the appropriate
-default repository could be made as well.
-
-
-git-daemon as regular daemon for virtual hosts::
-	To set up `git-daemon` as a regular, non-inetd service that
-	handles repositories for multiple virtual hosts based on
-	their IP addresses, start the daemon like this:
-+
-------------------------------------------------
-	git-daemon --verbose --export-all
-		--interpolated-path=/pub/%IP/%D
-		/pub/192.168.1.200/software
-		/pub/10.10.220.23/software
-------------------------------------------------
-+
-In this example, the root-level directory `/pub` will contain
-a subdirectory for each virtual host IP address supported.
-Repositories can still be accessed by hostname though, assuming
-they correspond to these IP addresses.
-
-selectively enable/disable services per repository::
-	To enable `git-archive --remote` and disable `git-fetch` against
-	a repository, have the following in the configuration file in the
-	repository (that is the file 'config' next to 'HEAD', 'refs' and
-	'objects').
-+
-----------------------------------------------------------------
-	[daemon]
-		uploadpack = false
-		uploadarchive = true
-----------------------------------------------------------------
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki
-<yoshfuji@linux-ipv6.org> and the git-list <git@vger.kernel.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-describe.txt

@@ -1,126 +0,0 @@
-git-describe(1)
-===============
-
-NAME
-----
-git-describe - Show the most recent tag that is reachable from a commit
-
-
-SYNOPSIS
---------
-'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
-
-DESCRIPTION
------------
-The command finds the most recent tag that is reachable from a
-commit, and if the commit itself is pointed at by the tag, shows
-the tag.  Otherwise, it suffixes the tag name with the number of
-additional commits and the abbreviated object name of the commit.
-
-
-OPTIONS
--------
-<committish>::
-	The object name of the committish.
-
---all::
-	Instead of using only the annotated tags, use any ref
-	found in `.git/refs/`.
-
---tags::
-	Instead of using only the annotated tags, use any tag
-	found in `.git/refs/tags`.
-
---contains::
-	Instead of finding the tag that predates the commit, find
-	the tag that comes after the commit, and thus contains it.
-	Automatically implies --tags.
-
---abbrev=<n>::
-	Instead of using the default 8 hexadecimal digits as the
-	abbreviated object name, use <n> digits.
-
---candidates=<n>::
-	Instead of considering only the 10 most recent tags as
-	candidates to describe the input committish consider
-	up to <n> candidates.  Increasing <n> above 10 will take
-	slightly longer but may produce a more accurate result.
-
---debug::
-	Verbosely display information about the searching strategy
-	being employed to standard error.  The tag name will still
-	be printed to standard out.
-
-EXAMPLES
---------
-
-With something like git.git current tree, I get:
-
-	[torvalds@g5 git]$ git-describe parent
-	v1.0.4-14-g2414721
-
-i.e. the current head of my "parent" branch is based on v1.0.4,
-but since it has a handful commits on top of that,
-describe has added the number of additional commits ("14") and
-an abbreviated object name for the commit itself ("2414721")
-at the end.
-
-The number of additional commits is the number
-of commits which would be displayed by "git log v1.0.4..parent".
-The hash suffix is "-g" + 7-char abbreviation for the tip commit
-of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
-
-Doing a "git-describe" on a tag-name will just show the tag name:
-
-	[torvalds@g5 git]$ git-describe v1.0.4
-	v1.0.4
-
-With --all, the command can use branch heads as references, so
-the output shows the reference path as well:
-
-	[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
-	tags/v1.0.0-21-g975b
-
-	[torvalds@g5 git]$ git describe --all HEAD^
-	heads/lt/describe-7-g975b
-
-With --abbrev set to 0, the command can be used to find the
-closest tagname without any suffix:
-
-	[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
-	tags/v1.0.0
-
-SEARCH STRATEGY
----------------
-
-For each committish supplied "git describe" will first look for
-a tag which tags exactly that commit.  Annotated tags will always
-be preferred over lightweight tags, and tags with newer dates will
-always be preferred over tags with older dates.  If an exact match
-is found, its name will be output and searching will stop.
-
-If an exact match was not found "git describe" will walk back
-through the commit history to locate an ancestor commit which
-has been tagged.  The ancestor's tag will be output along with an
-abbreviation of the input committish's SHA1.
-
-If multiple tags were found during the walk then the tag which
-has the fewest commits different from the input committish will be
-selected and output.  Here fewest commits different is defined as
-the number of commits which would be shown by "git log tag..input"
-will be the smallest number of commits possible.
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>, but somewhat
-butchered by Junio C Hamano <junkio@cox.net>.  Later significantly
-updated by Shawn Pearce <spearce@spearce.org>.
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-diff-files.txt

@@ -1,60 +0,0 @@
-git-diff-files(1)
-=================
-
-NAME
-----
-git-diff-files - Compares files in the working tree and the index
-
-
-SYNOPSIS
---------
-'git-diff-files' [-q] [-0|-1|-2|-3|-c|--cc|--no-index] [<common diff options>] [<path>...]
-
-DESCRIPTION
------------
-Compares the files in the working tree and the index.  When paths
-are specified, compares only those named paths.  Otherwise all
-entries in the index are compared.  The output format is the
-same as "git-diff-index" and "git-diff-tree".
-
-OPTIONS
--------
-include::diff-options.txt[]
-
--1 -2 -3 or --base --ours --theirs, and -0::
-	Diff against the "base" version, "our branch" or "their
-	branch" respectively.  With these options, diffs for
-	merged entries are not shown.
-+
-The default is to diff against our branch (-2) and the
-cleanly resolved paths.  The option -0 can be given to
-omit diff output for unmerged entries and just show "Unmerged".
-
--c,--cc::
-	This compares stage 2 (our branch), stage 3 (their
-	branch) and the working tree file and outputs a combined
-	diff, similar to the way 'diff-tree' shows a merge
-	commit with these flags.
-
---no-index::
-	Compare the two given files / directories.
-
--q::
-	Remain silent even on nonexistent files
-
-Output format
--------------
-include::diff-format.txt[]
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-diff-index.txt

@@ -1,132 +0,0 @@
-git-diff-index(1)
-=================
-
-NAME
-----
-git-diff-index - Compares content and mode of blobs between the index and repository
-
-
-SYNOPSIS
---------
-'git-diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
-
-DESCRIPTION
------------
-Compares the content and mode of the blobs found via a tree
-object with the content of the current index and, optionally
-ignoring the stat state of the file on disk.  When paths are
-specified, compares only those named paths.  Otherwise all
-entries in the index are compared.
-
-OPTIONS
--------
-include::diff-options.txt[]
-
-<tree-ish>::
-	The id of a tree object to diff against.
-
---cached::
-	do not consider the on-disk file at all
-
--m::
-	By default, files recorded in the index but not checked
-	out are reported as deleted.  This flag makes
-	"git-diff-index" say that all non-checked-out files are up
-	to date.
-
-Output format
--------------
-include::diff-format.txt[]
-
-Operating Modes
----------------
-You can choose whether you want to trust the index file entirely
-(using the '--cached' flag) or ask the diff logic to show any files
-that don't match the stat state as being "tentatively changed".  Both
-of these operations are very useful indeed.
-
-Cached Mode
------------
-If '--cached' is specified, it allows you to ask:
-
-	show me the differences between HEAD and the current index
-	contents (the ones I'd write with a "git-write-tree")
-
-For example, let's say that you have worked on your working directory, updated
-some files in the index and are ready to commit. You want to see exactly
-*what* you are going to commit, without having to write a new tree
-object and compare it that way, and to do that, you just do
-
-	git-diff-index --cached HEAD
-
-Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
-done an "git-update-index" to make that effective in the index file.
-"git-diff-files" wouldn't show anything at all, since the index file
-matches my working directory. But doing a "git-diff-index" does:
-
-  torvalds@ppc970:~/git> git-diff-index --cached HEAD
-  -100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        commit.c
-  +100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        git-commit.c
-
-You can see easily that the above is a rename.
-
-In fact, "git-diff-index --cached" *should* always be entirely equivalent to
-actually doing a "git-write-tree" and comparing that. Except this one is much
-nicer for the case where you just want to check where you are.
-
-So doing a "git-diff-index --cached" is basically very useful when you are
-asking yourself "what have I already marked for being committed, and
-what's the difference to a previous tree".
-
-Non-cached Mode
----------------
-The "non-cached" mode takes a different approach, and is potentially
-the more useful of the two in that what it does can't be emulated with
-a "git-write-tree" + "git-diff-tree". Thus that's the default mode.
-The non-cached version asks the question:
-
-  show me the differences between HEAD and the currently checked out
-  tree - index contents _and_ files that aren't up-to-date
-
-which is obviously a very useful question too, since that tells you what
-you *could* commit. Again, the output matches the "git-diff-tree -r"
-output to a tee, but with a twist.
-
-The twist is that if some file doesn't match the index, we don't have
-a backing store thing for it, and we use the magic "all-zero" sha1 to
-show that. So let's say that you have edited `kernel/sched.c`, but
-have not actually done a "git-update-index" on it yet - there is no
-"object" associated with the new state, and you get:
-
-  torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
-  *100644->100664 blob    7476bb......->000000......      kernel/sched.c
-
-i.e., it shows that the tree has changed, and that `kernel/sched.c` has is
-not up-to-date and may contain new stuff. The all-zero sha1 means that to
-get the real diff, you need to look at the object in the working directory
-directly rather than do an object-to-object diff.
-
-NOTE: As with other commands of this type, "git-diff-index" does not
-actually look at the contents of the file at all. So maybe
-`kernel/sched.c` hasn't actually changed, and it's just that you
-touched it. In either case, it's a note that you need to
-"git-update-index" it to make the index be in sync.
-
-NOTE: You can have a mixture of files show up as "has been updated"
-and "is still dirty in the working directory" together. You can always
-tell which file is in which state, since the "has been updated" ones
-show a valid sha1, and the "not in sync with the index" ones will
-always have the special all-zero sha1.
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-diff-tree.txt

@@ -1,168 +0,0 @@
-git-diff-tree(1)
-================
-
-NAME
-----
-git-diff-tree - Compares the content and mode of blobs found via two tree objects
-
-
-SYNOPSIS
---------
-[verse]
-'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
-	      [-t] [-r] [-c | --cc] [--root] [<common diff options>]
-	      <tree-ish> [<tree-ish>] [<path>...]
-
-DESCRIPTION
------------
-Compares the content and mode of the blobs found via two tree objects.
-
-If there is only one <tree-ish> given, the commit is compared with its parents
-(see --stdin below).
-
-Note that "git-diff-tree" can use the tree encapsulated in a commit object.
-
-OPTIONS
--------
-include::diff-options.txt[]
-
-<tree-ish>::
-	The id of a tree object.
-
-<path>...::
-	If provided, the results are limited to a subset of files
-	matching one of these prefix strings.
-	i.e., file matches `/^<pattern1>|<pattern2>|.../`
-	Note that this parameter does not provide any wildcard or regexp
-	features.
-
--r::
-        recurse into sub-trees
-
--t::
-	show tree entry itself as well as subtrees.  Implies -r.
-
---root::
-	When '--root' is specified the initial commit will be showed as a big
-	creation event. This is equivalent to a diff against the NULL tree.
-
---stdin::
-	When '--stdin' is specified, the command does not take
-	<tree-ish> arguments from the command line.  Instead, it
-	reads either one <commit> or a pair of <tree-ish>
-	separated with a single space from its standard input.
-+
-When a single commit is given on one line of such input, it compares
-the commit with its parents.  The following flags further affects its
-behavior.  This does not apply to the case where two <tree-ish>
-separated with a single space are given.
-
--m::
-	By default, "git-diff-tree --stdin" does not show
-	differences for merge commits.  With this flag, it shows
-	differences to that commit from all of its parents. See
-	also '-c'.
-
--s::
-	By default, "git-diff-tree --stdin" shows differences,
-	either in machine-readable form (without '-p') or in patch
-	form (with '-p').  This output can be suppressed.  It is
-	only useful with '-v' flag.
-
--v::
-	This flag causes "git-diff-tree --stdin" to also show
-	the commit message before the differences.
-
-include::pretty-options.txt[]
-
---no-commit-id::
-	git-diff-tree outputs a line with the commit ID when
-	applicable.  This flag suppressed the commit ID output.
-
--c::
-	This flag changes the way a merge commit is displayed
-	(which means it is useful only when the command is given
-	one <tree-ish>, or '--stdin').  It shows the differences
-	from each of the parents to the merge result simultaneously
-	instead of showing pairwise diff between a parent and the
-	result one at a time (which is what the '-m' option does).
-	Furthermore, it lists only files which were modified
-	from all parents.
-
---cc::
-	This flag changes the way a merge commit patch is displayed,
-	in a similar way to the '-c' option. It implies the '-c'
-	and '-p' options and further compresses the patch output
-	by omitting hunks that show differences from only one
-	parent, or show the same change from all but one parent
-	for an Octopus merge.  When this optimization makes all
-	hunks disappear, the commit itself and the commit log
-	message is not shown, just like in any other "empty diff" case.
-
---always::
-	Show the commit itself and the commit log message even
-	if the diff itself is empty.
-
-
-include::pretty-formats.txt[]
-
-
-Limiting Output
----------------
-If you're only interested in differences in a subset of files, for
-example some architecture-specific files, you might do:
-
-	git-diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
-
-and it will only show you what changed in those two directories.
-
-Or if you are searching for what changed in just `kernel/sched.c`, just do
-
-	git-diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
-
-and it will ignore all differences to other files.
-
-The pattern is always the prefix, and is matched exactly.  There are no
-wildcards.  Even stricter, it has to match a complete path component.
-I.e. "foo" does not pick up `foobar.h`.  "foo" does match `foo/bar.h`
-so it can be used to name subdirectories.
-
-An example of normal usage is:
-
-  torvalds@ppc970:~/git> git-diff-tree 5319e4......
-  *100664->100664 blob    ac348b.......->a01513.......      git-fsck-objects.c
-
-which tells you that the last commit changed just one file (it's from
-this one:
-
------------------------------------------------------------------------------
-commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
-tree 5319e4d609cdd282069cc4dce33c1db559539b03
-parent b4e628ea30d5ab3606119d2ea5caeab141d38df7
-author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
-committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
-
-Make "git-fsck-objects" print out all the root commits it finds.
-
-Once I do the reference tracking, I'll also make it print out all the
-HEAD commits it finds, which is even more interesting.
------------------------------------------------------------------------------
-
-in case you care).
-
-Output format
--------------
-include::diff-format.txt[]
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-diff.txt

@@ -1,171 +0,0 @@
-git-diff(1)
-===========
-
-NAME
-----
-git-diff - Show changes between commits, commit and working tree, etc
-
-
-SYNOPSIS
---------
-'git-diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
-
-DESCRIPTION
------------
-Show changes between two trees, a tree and the working tree, a
-tree and the index file, or the index file and the working tree.
-
-'git-diff' [--options] [--] [<path>...]::
-
-	This form is to view the changes you made relative to
-	the index (staging area for the next commit).  In other
-	words, the differences are what you _could_ tell git to
-	further add to the index but you still haven't.  You can
-	stage these changes by using linkgit:git-add[1].
-+
-If exactly two paths are given, and at least one is untracked,
-compare the two files / directories. This behavior can be
-forced by --no-index.
-
-'git-diff' [--options] --cached [<commit>] [--] [<path>...]::
-
-	This form is to view the changes you staged for the next
-	commit relative to the named <commit>.  Typically you
-	would want comparison with the latest commit, so if you
-	do not give <commit>, it defaults to HEAD.
-
-'git-diff' [--options] <commit> [--] [<path>...]::
-
-	This form is to view the changes you have in your
-	working tree relative to the named <commit>.  You can
-	use HEAD to compare it with the latest commit, or a
-	branch name to compare with the tip of a different
-	branch.
-
-'git-diff' [--options] <commit> <commit> [--] [<path>...]::
-
-	This is to view the changes between two arbitrary
-	<commit>.
-
-'git-diff' [--options] <commit>..<commit> [--] [<path>...]::
-
-	This is synonymous to the previous form.  If <commit> on
-	one side is omitted, it will have the same effect as
-	using HEAD instead.
-
-'git-diff' [--options] <commit>\...<commit> [--] [<path>...]::
-
-	This form is to view the changes on the branch containing
-	and up to the second <commit>, starting at a common ancestor
-	of both <commit>.  "git-diff A\...B" is equivalent to
-	"git-diff $(git-merge-base A B) B".  You can omit any one
-	of <commit>, which has the same effect as using HEAD instead.
-
-Just in case if you are doing something exotic, it should be
-noted that all of the <commit> in the above description, except
-for the last two forms that use ".." notations, can be any
-<tree-ish>.
-
-For a more complete list of ways to spell <commit>, see
-"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
-However, "diff" is about comparing two _endpoints_, not ranges,
-and the range notations ("<commit>..<commit>" and
-"<commit>\...<commit>") do not mean a range as defined in the
-"SPECIFYING RANGES" section in linkgit:git-rev-parse[1].
-
-OPTIONS
--------
-:git-diff: 1
-include::diff-options.txt[]
-
-<path>...::
-	The <paths> parameters, when given, are used to limit
-	the diff to the named paths (you can give directory
-	names and get diff for all files under them).
-
-Output format
--------------
-include::diff-format.txt[]
-
-EXAMPLES
---------
-
-Various ways to check your working tree::
-+
-------------
-$ git diff            <1>
-$ git diff --cached   <2>
-$ git diff HEAD       <3>
-------------
-+
-<1> Changes in the working tree not yet staged for the next commit.
-<2> Changes between the index and your last commit; what you
-would be committing if you run "git commit" without "-a" option.
-<3> Changes in the working tree since your last commit; what you
-would be committing if you run "git commit -a"
-
-Comparing with arbitrary commits::
-+
-------------
-$ git diff test            <1>
-$ git diff HEAD -- ./test  <2>
-$ git diff HEAD^ HEAD      <3>
-------------
-+
-<1> Instead of using the tip of the current branch, compare with the
-tip of "test" branch.
-<2> Instead of comparing with the tip of "test" branch, compare with
-the tip of the current branch, but limit the comparison to the
-file "test".
-<3> Compare the version before the last commit and the last commit.
-
-Comparing branches::
-+
-------------
-$ git diff topic master    <1>
-$ git diff topic..master   <2>
-$ git diff topic...master  <3>
-------------
-+
-<1> Changes between the tips of the topic and the master branches.
-<2> Same as above.
-<3> Changes that occurred on the master branch since when the topic
-branch was started off it.
-
-Limiting the diff output::
-+
-------------
-$ git diff --diff-filter=MRC            <1>
-$ git diff --name-status                <2>
-$ git diff arch/i386 include/asm-i386   <3>
-------------
-+
-<1> Show only modification, rename and copy, but not addition
-nor deletion.
-<2> Show only names and the nature of change, but not actual
-diff output.
-<3> Limit diff output to named subtrees.
-
-Munging the diff output::
-+
-------------
-$ git diff --find-copies-harder -B -C  <1>
-$ git diff -R                          <2>
-------------
-+
-<1> Spend extra cycles to find renames, copies and complete
-rewrites (very expensive).
-<2> Output diff in reverse.
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-fast-export.txt

@@ -1,83 +0,0 @@
-git-fast-export(1)
-==================
-
-NAME
-----
-git-fast-export - Git data exporter
-
-
-SYNOPSIS
---------
-'git-fast-export [options]' | 'git-fast-import'
-
-DESCRIPTION
------------
-This program dumps the given revisions in a form suitable to be piped
-into linkgit:git-fast-import[1].
-
-You can use it as a human readable bundle replacement (see
-linkgit:git-bundle[1]), or as a kind of an interactive
-linkgit:git-filter-branch[1].
-
-
-OPTIONS
--------
---progress=<n>::
-	Insert 'progress' statements every <n> objects, to be shown by
-	linkgit:git-fast-import[1] during import.
-
---signed-tags=(verbatim|warn|strip|abort)::
-	Specify how to handle signed tags.  Since any transformation
-	after the export can change the tag names (which can also happen
-	when excluding revisions) the signatures will not match.
-+
-When asking to 'abort' (which is the default), this program will die
-when encountering a signed tag.  With 'strip', the tags will be made
-unsigned, with 'verbatim', they will be silently exported
-and with 'warn', they will be exported, but you will see a warning.
-
-
-EXAMPLES
---------
-
--------------------------------------------------------------------
-$ git fast-export --all | (cd /empty/repository && git fast-import)
--------------------------------------------------------------------
-
-This will export the whole repository and import it into the existing
-empty repository.  Except for reencoding commits that are not in
-UTF-8, it would be a one-to-one mirror.
-
------------------------------------------------------
-$ git fast-export master~5..master |
-	sed "s|refs/heads/master|refs/heads/other|" |
-	git fast-import
------------------------------------------------------
-
-This makes a new branch called 'other' from 'master~5..master'
-(i.e. if 'master' has linear history, it will take the last 5 commits).
-
-Note that this assumes that none of the blobs and commit messages
-referenced by that revision range contains the string
-'refs/heads/master'.
-
-
-Limitations
------------
-
-Since linkgit:git-fast-import[1] cannot tag trees, you will not be
-able to export the linux-2.6.git repository completely, as it contains
-a tag referencing a tree instead of a commit.
-
-
-Author
-------
-Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
-
-Documentation
---------------
-Documentation by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-fetch-pack.txt

@@ -1,96 +0,0 @@
-git-fetch-pack(1)
-=================
-
-NAME
-----
-git-fetch-pack - Receive missing objects from another repository
-
-
-SYNOPSIS
---------
-'git-fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
-
-DESCRIPTION
------------
-Usually you would want to use linkgit:git-fetch[1] which is a
-higher level wrapper of this command instead.
-
-Invokes 'git-upload-pack' on a potentially remote repository,
-and asks it to send objects missing from this repository, to
-update the named heads.  The list of commits available locally
-is found out by scanning local $GIT_DIR/refs/ and sent to
-'git-upload-pack' running on the other end.
-
-This command degenerates to download everything to complete the
-asked refs from the remote side when the local side does not
-have a common ancestor commit.
-
-
-OPTIONS
--------
-\--all::
-	Fetch all remote refs.
-
-\--quiet, \-q::
-	Pass '-q' flag to 'git-unpack-objects'; this makes the
-	cloning process less verbose.
-
-\--keep, \-k::
-	Do not invoke 'git-unpack-objects' on received data, but
-	create a single packfile out of it instead, and store it
-	in the object database. If provided twice then the pack is
-	locked against repacking.
-
-\--thin::
-	Spend extra cycles to minimize the number of objects to be sent.
-	Use it on slower connection.
-
-\--upload-pack=<git-upload-pack>::
-	Use this to specify the path to 'git-upload-pack' on the
-	remote side, if is not found on your $PATH.
-	Installations of sshd ignores the user's environment
-	setup scripts for login shells (e.g. .bash_profile) and
-	your privately installed git may not be found on the system
-	default $PATH.  Another workaround suggested is to set
-	up your $PATH in ".bashrc", but this flag is for people
-	who do not want to pay the overhead for non-interactive
-	shells by having a lean .bashrc file (they set most of
-	the things up in .bash_profile).
-
-\--exec=<git-upload-pack>::
-	Same as \--upload-pack=<git-upload-pack>.
-
-\--depth=<n>::
-	Limit fetching to ancestor-chains not longer than n.
-
-\--no-progress::
-	Do not show the progress.
-
-\-v::
-	Run verbosely.
-
-<host>::
-	A remote host that houses the repository.  When this
-	part is specified, 'git-upload-pack' is invoked via
-	ssh.
-
-<directory>::
-	The repository to sync from.
-
-<refs>...::
-	The remote heads to update from. This is relative to
-	$GIT_DIR (e.g. "HEAD", "refs/heads/master").  When
-	unspecified, update from all heads the remote side has.
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-fetch.txt

@@ -1,56 +0,0 @@
-git-fetch(1)
-============
-
-NAME
-----
-git-fetch - Download objects and refs from another repository
-
-
-SYNOPSIS
---------
-'git-fetch' <options> <repository> <refspec>...
-
-
-DESCRIPTION
------------
-Fetches named heads or tags from another repository, along with
-the objects necessary to complete them.
-
-The ref names and their object names of fetched refs are stored
-in `.git/FETCH_HEAD`.  This information is left for a later merge
-operation done by "git merge".
-
-When <refspec> stores the fetched result in tracking branches,
-the tags that point at these branches are automatically
-followed.  This is done by first fetching from the remote using
-the given <refspec>s, and if the repository has objects that are
-pointed by remote tags that it does not yet have, then fetch
-those missing tags.  If the other end has tags that point at
-branches you are not interested in, you will not get them.
-
-
-OPTIONS
--------
-include::fetch-options.txt[]
-
-include::pull-fetch-param.txt[]
-
-include::urls-remotes.txt[]
-
-SEE ALSO
---------
-linkgit:git-pull[1]
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org> and
-Junio C Hamano <junkio@cox.net>
-
-Documentation
--------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-filter-branch.txt

@@ -1,298 +0,0 @@
-git-filter-branch(1)
-====================
-
-NAME
-----
-git-filter-branch - Rewrite branches
-
-SYNOPSIS
---------
-[verse]
-'git-filter-branch' [--env-filter <command>] [--tree-filter <command>]
-	[--index-filter <command>] [--parent-filter <command>]
-	[--msg-filter <command>] [--commit-filter <command>]
-	[--tag-name-filter <command>] [--subdirectory-filter <directory>]
-	[--original <namespace>] [-d <directory>] [-f | --force]
-	[<rev-list options>...]
-
-DESCRIPTION
------------
-Lets you rewrite git revision history by rewriting the branches mentioned
-in the <rev-list options>, applying custom filters on each revision.
-Those filters can modify each tree (e.g. removing a file or running
-a perl rewrite on all files) or information about each commit.
-Otherwise, all information (including original commit times or merge
-information) will be preserved.
-
-The command will only rewrite the _positive_ refs mentioned in the
-command line (i.e. if you pass 'a..b', only 'b' will be rewritten).
-If you specify no filters, the commits will be recommitted without any
-changes, which would normally have no effect.  Nevertheless, this may be
-useful in the future for compensating for some git bugs or such,
-therefore such a usage is permitted.
-
-*WARNING*! The rewritten history will have different object names for all
-the objects and will not converge with the original branch.  You will not
-be able to easily push and distribute the rewritten branch on top of the
-original branch.  Please do not use this command if you do not know the
-full implications, and avoid using it anyway, if a simple single commit
-would suffice to fix your problem.
-
-Always verify that the rewritten version is correct: The original refs,
-if different from the rewritten ones, will be stored in the namespace
-'refs/original/'.
-
-Note that since this operation is extensively I/O expensive, it might
-be a good idea to redirect the temporary directory off-disk with the
-'-d' option, e.g. on tmpfs.  Reportedly the speedup is very noticeable.
-
-
-Filters
-~~~~~~~
-
-The filters are applied in the order as listed below.  The <command>
-argument is always evaluated in shell using the 'eval' command (with the
-notable exception of the commit filter, for technical reasons).
-Prior to that, the $GIT_COMMIT environment variable will be set to contain
-the id of the commit being rewritten.  Also, GIT_AUTHOR_NAME,
-GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,
-and GIT_COMMITTER_DATE are set according to the current commit.
-
-A 'map' function is available that takes an "original sha1 id" argument
-and outputs a "rewritten sha1 id" if the commit has been already
-rewritten, and "original sha1 id" otherwise; the 'map' function can
-return several ids on separate lines if your commit filter emitted
-multiple commits.
-
-
-OPTIONS
--------
-
---env-filter <command>::
-	This is the filter for modifying the environment in which
-	the commit will be performed.  Specifically, you might want
-	to rewrite the author/committer name/email/time environment
-	variables (see linkgit:git-commit[1] for details).  Do not forget
-	to re-export the variables.
-
---tree-filter <command>::
-	This is the filter for rewriting the tree and its contents.
-	The argument is evaluated in shell with the working
-	directory set to the root of the checked out tree.  The new tree
-	is then used as-is (new files are auto-added, disappeared files
-	are auto-removed - neither .gitignore files nor any other ignore
-	rules *HAVE ANY EFFECT*!).
-
---index-filter <command>::
-	This is the filter for rewriting the index.  It is similar to the
-	tree filter but does not check out the tree, which makes it much
-	faster.  For hairy cases, see linkgit:git-update-index[1].
-
---parent-filter <command>::
-	This is the filter for rewriting the commit's parent list.
-	It will receive the parent string on stdin and shall output
-	the new parent string on stdout.  The parent string is in
-	a format accepted by linkgit:git-commit-tree[1]: empty for
-	the initial commit, "-p parent" for a normal commit and
-	"-p parent1 -p parent2 -p parent3 ..." for a merge commit.
-
---msg-filter <command>::
-	This is the filter for rewriting the commit messages.
-	The argument is evaluated in the shell with the original
-	commit message on standard input; its standard output is
-	used as the new commit message.
-
---commit-filter <command>::
-	This is the filter for performing the commit.
-	If this filter is specified, it will be called instead of the
-	linkgit:git-commit-tree[1] command, with arguments of the form
-	"<TREE_ID> [-p <PARENT_COMMIT_ID>]..." and the log message on
-	stdin.  The commit id is expected on stdout.
-+
-As a special extension, the commit filter may emit multiple
-commit ids; in that case, ancestors of the original commit will
-have all of them as parents.
-+
-You can use the 'map' convenience function in this filter, and other
-convenience functions, too.  For example, calling 'skip_commit "$@"'
-will leave out the current commit (but not its changes! If you want
-that, use linkgit:git-rebase[1] instead).
-
---tag-name-filter <command>::
-	This is the filter for rewriting tag names. When passed,
-	it will be called for every tag ref that points to a rewritten
-	object (or to a tag object which points to a rewritten object).
-	The original tag name is passed via standard input, and the new
-	tag name is expected on standard output.
-+
-The original tags are not deleted, but can be overwritten;
-use "--tag-name-filter cat" to simply update the tags.  In this
-case, be very careful and make sure you have the old tags
-backed up in case the conversion has run afoul.
-+
-Note that there is currently no support for proper rewriting of
-tag objects; in layman terms, if the tag has a message or signature
-attached, the rewritten tag won't have it.  Sorry.  (It is by
-definition impossible to preserve signatures at any rate.)
-
---subdirectory-filter <directory>::
-	Only look at the history which touches the given subdirectory.
-	The result will contain that directory (and only that) as its
-	project root.
-
---original <namespace>::
-	Use this option to set the namespace where the original commits
-	will be stored. The default value is 'refs/original'.
-
--d <directory>::
-	Use this option to set the path to the temporary directory used for
-	rewriting.  When applying a tree filter, the command needs to
-	temporary checkout the tree to some directory, which may consume
-	considerable space in case of large projects.  By default it
-	does this in the '.git-rewrite/' directory but you can override
-	that choice by this parameter.
-
--f|--force::
-	`git filter-branch` refuses to start with an existing temporary
-	directory or when there are already refs starting with
-	'refs/original/', unless forced.
-
-<rev-list-options>::
-	When options are given after the new branch name, they will
-	be passed to linkgit:git-rev-list[1].  Only commits in the resulting
-	output will be filtered, although the filtered commits can still
-	reference parents which are outside of that set.
-
-
-Examples
---------
-
-Suppose you want to remove a file (containing confidential information
-or copyright violation) from all commits:
-
--------------------------------------------------------
-git filter-branch --tree-filter 'rm filename' HEAD
--------------------------------------------------------
-
-A significantly faster version:
-
---------------------------------------------------------------------------
-git filter-branch --index-filter 'git update-index --remove filename' HEAD
---------------------------------------------------------------------------
-
-Now, you will get the rewritten history saved in HEAD.
-
-To set a commit (which typically is at the tip of another
-history) to be the parent of the current initial commit, in
-order to paste the other history behind the current history:
-
--------------------------------------------------------------------
-git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD
--------------------------------------------------------------------
-
-(if the parent string is empty - which happens when we are dealing with
-the initial commit - add graftcommit as a parent).  Note that this assumes
-history with a single root (that is, no merge without common ancestors
-happened).  If this is not the case, use:
-
---------------------------------------------------------------------------
-git filter-branch --parent-filter \
-	'cat; test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>"' HEAD
---------------------------------------------------------------------------
-
-or even simpler:
-
------------------------------------------------
-echo "$commit-id $graft-id" >> .git/info/grafts
-git filter-branch $graft-id..HEAD
------------------------------------------------
-
-To remove commits authored by "Darl McBribe" from the history:
-
-------------------------------------------------------------------------------
-git filter-branch --commit-filter '
-	if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
-	then
-		skip_commit "$@";
-	else
-		git commit-tree "$@";
-	fi' HEAD
-------------------------------------------------------------------------------
-
-The function 'skip_commit' is defined as follows:
-
---------------------------
-skip_commit()
-{
-	shift;
-	while [ -n "$1" ];
-	do
-		shift;
-		map "$1";
-		shift;
-	done;
-}
---------------------------
-
-The shift magic first throws away the tree id and then the -p
-parameters.  Note that this handles merges properly! In case Darl
-committed a merge between P1 and P2, it will be propagated properly
-and all children of the merge will become merge commits with P1,P2
-as their parents instead of the merge commit.
-
-
-To restrict rewriting to only part of the history, specify a revision
-range in addition to the new branch name.  The new branch name will
-point to the top-most revision that a 'git rev-list' of this range
-will print.
-
-*NOTE* the changes introduced by the commits, and which are not reverted
-by subsequent commits, will still be in the rewritten branch. If you want
-to throw out _changes_ together with the commits, you should use the
-interactive mode of linkgit:git-rebase[1].
-
-
-Consider this history:
-
-------------------
-     D--E--F--G--H
-    /     /
-A--B-----C
-------------------
-
-To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use:
-
---------------------------------
-git filter-branch ... C..H
---------------------------------
-
-To rewrite commits E,F,G,H, use one of these:
-
-----------------------------------------
-git filter-branch ... C..H --not D
-git filter-branch ... D..H --not C
-----------------------------------------
-
-To move the whole tree into a subdirectory, or remove it from there:
-
----------------------------------------------------------------
-git filter-branch --index-filter \
-	'git ls-files -s | sed "s-\t-&newsubdir/-" |
-		GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
-			git update-index --index-info &&
-	 mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
----------------------------------------------------------------
-
-
-Author
-------
-Written by Petr "Pasky" Baudis <pasky@suse.cz>,
-and the git list <git@vger.kernel.org>
-
-Documentation
---------------
-Documentation by Petr Baudis and the git list.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-fmt-merge-msg.txt

@@ -1,62 +0,0 @@
-git-fmt-merge-msg(1)
-====================
-
-NAME
-----
-git-fmt-merge-msg - Produce a merge commit message
-
-
-SYNOPSIS
---------
-[verse]
-git-fmt-merge-msg [--summary | --no-summary] <$GIT_DIR/FETCH_HEAD
-git-fmt-merge-msg [--summary | --no-summary] -F <file>
-
-DESCRIPTION
------------
-Takes the list of merged objects on stdin and produces a suitable
-commit message to be used for the merge commit, usually to be
-passed as the '<merge-message>' argument of `git-merge`.
-
-This script is intended mostly for internal use by scripts
-automatically invoking `git-merge`.
-
-OPTIONS
--------
-
---summary::
-	In addition to branch names, populate the log message with
-	one-line descriptions from the actual commits that are being
-	merged.
-
---no-summary::
-	Do not list one-line descriptions from the actual commits being
-	merged.
-
---file <file>, -F <file>::
-	Take the list of merged objects from <file> instead of
-	stdin.
-
-CONFIGURATION
--------------
-
-merge.summary::
-	Whether to include summaries of merged commits in newly
-	merge commit messages. False by default.
-
-SEE ALSO
---------
-linkgit:git-merge[1]
-
-
-Author
-------
-Written by Junio C Hamano <junkio@cox.net>
-
-Documentation
---------------
-Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-for-each-ref.txt

@@ -1,193 +0,0 @@
-git-for-each-ref(1)
-===================
-
-NAME
-----
-git-for-each-ref - Output information on each ref
-
-SYNOPSIS
---------
-[verse]
-'git-for-each-ref' [--count=<count>]\*
-                   [--shell|--perl|--python|--tcl]
-                   [--sort=<key>]\* [--format=<format>] [<pattern>]
-
-DESCRIPTION
------------
-
-Iterate over all refs that match `<pattern>` and show them
-according to the given `<format>`, after sorting them according
-to the given set of `<key>`.  If `<max>` is given, stop after
-showing that many refs.  The interpolated values in `<format>`
-can optionally be quoted as string literals in the specified
-host language allowing their direct evaluation in that language.
-
-OPTIONS
--------
-<count>::
-	By default the command shows all refs that match
-	`<pattern>`.  This option makes it stop after showing
-	that many refs.
-
-<key>::
-	A field name to sort on.  Prefix `-` to sort in
-	descending order of the value.  When unspecified,
-	`refname` is used.  More than one sort keys can be
-	given.
-
-<format>::
-	A string that interpolates `%(fieldname)` from the
-	object pointed at by a ref being shown.  If `fieldname`
-	is prefixed with an asterisk (`*`) and the ref points
-	at a tag object, the value for the field in the object
-	tag refers is used.  When unspecified, defaults to
-	`%(objectname) SPC %(objecttype) TAB %(refname)`.
-	It also interpolates `%%` to `%`, and `%xx` where `xx`
-	are hex digits interpolates to character with hex code
-	`xx`; for example `%00` interpolates to `\0` (NUL),
-	`%09` to `\t` (TAB) and `%0a` to `\n` (LF).
-
-<pattern>::
-	If given, the name of the ref is matched against this
-	using fnmatch(3).  Refs that do not match the pattern
-	are not shown.
-
---shell, --perl, --python, --tcl::
-	If given, strings that substitute `%(fieldname)`
-	placeholders are quoted as string literals suitable for
-	the specified host language.  This is meant to produce
-	a scriptlet that can directly be `eval`ed.
-
-
-FIELD NAMES
------------
-
-Various values from structured fields in referenced objects can
-be used to interpolate into the resulting output, or as sort
-keys.
-
-For all objects, the following names can be used:
-
-refname::
-	The name of the ref (the part after $GIT_DIR/).
-
-objecttype::
-	The type of the object (`blob`, `tree`, `commit`, `tag`).
-
-objectsize::
-	The size of the object (the same as `git-cat-file -s` reports).
-
-objectname::
-	The object name (aka SHA-1).
-
-In addition to the above, for commit and tag objects, the header
-field names (`tree`, `parent`, `object`, `type`, and `tag`) can
-be used to specify the value in the header field.
-
-Fields that have name-email-date tuple as its value (`author`,
-`committer`, and `tagger`) can be suffixed with `name`, `email`,
-and `date` to extract the named component.
-
-The first line of the message in a commit and tag object is
-`subject`, the remaining lines are `body`.  The whole message
-is `contents`.
-
-For sorting purposes, fields with numeric values sort in numeric
-order (`objectsize`, `authordate`, `committerdate`, `taggerdate`).
-All other fields are used to sort in their byte-value order.
-
-In any case, a field name that refers to a field inapplicable to
-the object referred by the ref does not cause an error.  It
-returns an empty string instead.
-
-As a special case for the date-type fields, you may specify a format for
-the date by adding one of `:default`, `:relative`, `:short`, `:local`,
-`:iso8601` or `:rfc2822` to the end of the fieldname; e.g.
-`%(taggerdate:relative)`.
-
-
-EXAMPLES
---------
-
-An example directly producing formatted text.  Show the most recent
-3 tagged commits::
-
-------------
-#!/bin/sh
-
-git-for-each-ref --count=3 --sort='-*authordate' \
---format='From: %(*authorname) %(*authoremail)
-Subject: %(*subject)
-Date: %(*authordate)
-Ref: %(*refname)
-
-%(*body)
-' 'refs/tags'
-------------
-
-
-A simple example showing the use of shell eval on the output,
-demonstrating the use of --shell.  List the prefixes of all heads::
-------------
-#!/bin/sh
-
-git-for-each-ref --shell --format="ref=%(refname)" refs/heads | \
-while read entry
-do
-	eval "$entry"
-	echo `dirname $ref`
-done
-------------
-
-
-A bit more elaborate report on tags, demonstrating that the format
-may be an entire script::
-------------
-#!/bin/sh
-
-fmt='
-	r=%(refname)
-	t=%(*objecttype)
-	T=${r#refs/tags/}
-
-	o=%(*objectname)
-	n=%(*authorname)
-	e=%(*authoremail)
-	s=%(*subject)
-	d=%(*authordate)
-	b=%(*body)
-
-	kind=Tag
-	if test "z$t" = z
-	then
-		# could be a lightweight tag
-		t=%(objecttype)
-		kind="Lightweight tag"
-		o=%(objectname)
-		n=%(authorname)
-		e=%(authoremail)
-		s=%(subject)
-		d=%(authordate)
-		b=%(body)
-	fi
-	echo "$kind $T points at a $t object $o"
-	if test "z$t" = zcommit
-	then
-		echo "The commit was authored by $n $e
-at $d, and titled
-
-    $s
-
-Its message reads as:
-"
-		echo "$b" | sed -e "s/^/    /"
-		echo
-	fi
-'
-
-eval=`git-for-each-ref --shell --format="$fmt" \
-	--sort='*objecttype' \
-	--sort=-taggerdate \
-	refs/tags`
-eval "$eval"
-------------

Documentation/git-format-patch.txt

@@ -1,208 +0,0 @@
-git-format-patch(1)
-===================
-
-NAME
-----
-git-format-patch - Prepare patches for e-mail submission
-
-
-SYNOPSIS
---------
-[verse]
-'git-format-patch' [-k] [-o <dir> | --stdout] [--thread]
-                   [--attach[=<boundary>] | --inline[=<boundary>]]
-                   [-s | --signoff] [<common diff options>]
-                   [-n | --numbered | -N | --no-numbered]
-                   [--start-number <n>] [--numbered-files]
-                   [--in-reply-to=Message-Id] [--suffix=.<sfx>]
-                   [--ignore-if-in-upstream]
-                   [--subject-prefix=Subject-Prefix]
-		   [ <since> | <revision range> ]
-
-DESCRIPTION
------------
-
-Prepare each commit with its patch in
-one file per commit, formatted to resemble UNIX mailbox format.
-The output of this command is convenient for e-mail submission or
-for use with linkgit:git-am[1].
-
-There are two ways to specify which commits to operate on.
-
-1. A single commit, <since>, specifies that the commits leading
-   to the tip of the current branch that are not in the history
-   that leads to the <since> to be output.
-
-2. Generic <revision range> expression (see "SPECIFYING
-   REVISIONS" section in linkgit:git-rev-parse[1]) means the
-   commits in the specified range.
-
-A single commit, when interpreted as a <revision range>
-expression, means "everything that leads to that commit", but
-if you write 'git format-patch <commit>', the previous rule
-applies to that command line and you do not get "everything
-since the beginning of the time".  If you want to format
-everything since project inception to one commit, say "git
-format-patch \--root <commit>" to make it clear that it is the
-latter case.
-
-By default, each output file is numbered sequentially from 1, and uses the
-first line of the commit message (massaged for pathname safety) as
-the filename. With the --numbered-files option, the output file names
-will only be numbers, without the first line of the commit appended.
-The names of the output files are printed to standard
-output, unless the --stdout option is specified.
-
-If -o is specified, output files are created in <dir>.  Otherwise
-they are created in the current working directory.
-
-If -n is specified, instead of "[PATCH] Subject", the first line
-is formatted as "[PATCH n/m] Subject".
-
-If given --thread, git-format-patch will generate In-Reply-To and
-References headers to make the second and subsequent patch mails appear
-as replies to the first mail; this also generates a Message-Id header to
-reference.
-
-OPTIONS
--------
-:git-format-patch: 1
-include::diff-options.txt[]
-
--<n>::
-	Limits the number of patches to prepare.
-
--o|--output-directory <dir>::
-	Use <dir> to store the resulting files, instead of the
-	current working directory.
-
--n|--numbered::
-	Name output in '[PATCH n/m]' format.
-
--N|--no-numbered::
-	Name output in '[PATCH]' format.
-
---start-number <n>::
-	Start numbering the patches at <n> instead of 1.
-
---numbered-files::
-	Output file names will be a simple number sequence
-	without the default first line of the commit appended.
-	Mutually exclusive with the --stdout option.
-
--k|--keep-subject::
-	Do not strip/add '[PATCH]' from the first line of the
-	commit log message.
-
--s|--signoff::
-	Add `Signed-off-by:` line to the commit message, using
-	the committer identity of yourself.
-
---stdout::
-	Print all commits to the standard output in mbox format,
-	instead of creating a file for each one.
-
---attach[=<boundary>]::
-	Create multipart/mixed attachment, the first part of
-	which is the commit message and the patch itself in the
-	second part, with "Content-Disposition: attachment".
-
---inline[=<boundary>]::
-	Create multipart/mixed attachment, the first part of
-	which is the commit message and the patch itself in the
-	second part, with "Content-Disposition: inline".
-
---thread::
-	Add In-Reply-To and References headers to make the second and
-	subsequent mails appear as replies to the first.  Also generates
-	the Message-Id header to reference.
-
---in-reply-to=Message-Id::
-	Make the first mail (or all the mails with --no-thread) appear as a
-	reply to the given Message-Id, which avoids breaking threads to
-	provide a new patch series.
-
---ignore-if-in-upstream::
-	Do not include a patch that matches a commit in
-	<until>..<since>.  This will examine all patches reachable
-	from <since> but not from <until> and compare them with the
-	patches being generated, and any patch that matches is
-	ignored.
-
---subject-prefix=<Subject-Prefix>::
-	Instead of the standard '[PATCH]' prefix in the subject
-	line, instead use '[<Subject-Prefix>]'. This
-	allows for useful naming of a patch series, and can be
-	combined with the --numbered option.
-
---suffix=.<sfx>::
-	Instead of using `.patch` as the suffix for generated
-	filenames, use specified suffix.  A common alternative is
-	`--suffix=.txt`.
-+
-Note that you would need to include the leading dot `.` if you
-want a filename like `0001-description-of-my-change.patch`, and
-the first letter does not have to be a dot.  Leaving it empty would
-not add any suffix.
-
-CONFIGURATION
--------------
-You can specify extra mail header lines to be added to each message
-in the repository configuration, new defaults for the subject prefix
-and file suffix, and number patches when outputting more than one.
-
-------------
-[format]
-        headers = "Organization: git-foo\n"
-        subjectprefix = CHANGE
-        suffix = .txt
-        numbered = auto
-------------
-
-
-EXAMPLES
---------
-
-git-format-patch -k --stdout R1..R2 | git-am -3 -k::
-	Extract commits between revisions R1 and R2, and apply
-	them on top of the current branch using `git-am` to
-	cherry-pick them.
-
-git-format-patch origin::
-	Extract all commits which are in the current branch but
-	not in the origin branch.  For each commit a separate file
-	is created in the current directory.
-
-git-format-patch \--root origin::
-	Extract all commits that lead to 'origin' since the
-	inception of the project.
-
-git-format-patch -M -B origin::
-	The same as the previous one.  Additionally, it detects
-	and handles renames and complete rewrites intelligently to
-	produce a renaming patch.  A renaming patch reduces the
-	amount of text output, and generally makes it easier to
-	review it.  Note that the "patch" program does not
-	understand renaming patches, so use it only when you know
-	the recipient uses git to apply your patch.
-
-git-format-patch -3::
-	Extract three topmost commits from the current branch
-	and format them as e-mailable patches.
-
-See Also
---------
-linkgit:git-am[1], linkgit:git-send-email[1]
-
-
-Author
-------
-Written by Junio C Hamano <junkio@cox.net>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite