git-gui 0.13

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: avoid mis-encoding the copyright message on Windows.
2010-09-14 22:42:37 +01:00 · 2010-09-13 20:41:42 +01:00 · 2010-09-13 19:25:55 +01:00 · 2010-08-18 23:19:24 +01:00 · 2010-08-12 21:37:32 +01:00 · 2010-08-12 21:35:09 +01:00
1341 changed files with 18379 additions and 241601 deletions
--- a/.gitattributes
+++ b/.gitattributes
@ -1,2 +1,3 @@
-* whitespace=!indent,trail,space
+*           encoding=US-ASCII
-*.[ch] whitespace
+git-gui.sh  encoding=UTF-8
 /po/*.po    encoding=UTF-8
--- a/.gitignore
+++ b/.gitignore
@ -1,172 +1,8 @@
-GIT-BUILD-OPTIONS
+.DS_Store
 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-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-web--browse
 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]
 config.mak
-autom4te.cache
+Git Gui.app*
-config.cache
+git-gui.tcl
-config.log
+GIT-VERSION-FILE
-config.status
+GIT-GUI-VARS
-config.mak.autogen
+git-gui
-config.mak.append
+lib/tclIndex
 configure
 tags
 TAGS
 cscope*
--- a/.mailmap
+++ b/.mailmap
@ -1,55 +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>
 Jay Soffian <jaysoffian+git@gmail.com>
 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>
--- a/361
+++ b/361
@ -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.
--- a/Documentation/.gitattributes
+++ b/Documentation/.gitattributes
@ -1 +0,0 @@
 *.txt whitespace
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@ -1,8 +0,0 @@
 *.xml
 *.html
 *.[1-8]
 *.made
 git.info
 howto-index.txt
 doc.dep
 cmds-*.txt
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@ -1,124 +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.
 - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
   [::], [==], nor [..]) for portability.
   - We do not use \{m,n\};
   - We do not use -E;
   - We do not use ? nor + (which are \{0,1\} and \{1,\}
     respectively in BRE) but that goes without saying as these
     are ERE elements not BRE (note that \? and \+ are not even part
     of BRE -- making them accessible from BRE is a GNU extension).
 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).
--- a/Documentation/Makefile
+++ b/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
--- a/Documentation/RelNotes-1.5.0.1.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.0.2.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.0.3.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.0.4.txt
+++ b/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
--- a/Documentation/RelNotes-1.5.0.5.txt
+++ b/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
--- a/Documentation/RelNotes-1.5.0.6.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.0.7.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.0.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.1.1.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.1.2.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.1.3.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.1.4.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.1.5.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.1.6.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.1.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.2.1.txt
+++ b/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
--- a/Documentation/RelNotes-1.5.2.2.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.2.3.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.2.4.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.2.5.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.2.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.3.1.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.3.2.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.3.3.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.3.4.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.3.5.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.3.6.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.3.7.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.3.8.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.3.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.4.1.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.4.2.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.4.3.txt
+++ b/Documentation/RelNotes-1.5.4.3.txt
@ -1,27 +0,0 @@
 GIT v1.5.4.3 Release Notes
 ==========================
 Fixes since v1.5.4.2
 --------------------
 * RPM spec used to pull in everything with 'git'.  This has been
   changed so that 'git' package contains just the core parts,
   and we now supply 'git-all' metapackage to slurp in everything.
   This should match end user's expectation better.
 * When some refs failed to update, git-push reported "failure"
   which was unclear if some other refs were updated or all of
   them failed atomically (the answer is the former).  Reworded
   the message to clarify this.
 * "git clone" from a repository whose HEAD was misconfigured
   did not set up the remote properly.  Now it tries to do
   better.
 * Updated git-push documentation to clarify what "matching"
   means, in order to reduce user confusion.
 * Updated git-add documentation to clarify "add -u" operates in
   the current subdirectory you are in, just like other commands.
 * git-gui updates to work on OSX and Windows better.
--- a/Documentation/RelNotes-1.5.4.4.txt
+++ b/Documentation/RelNotes-1.5.4.4.txt
@ -1,66 +0,0 @@
 GIT v1.5.4.4 Release Notes
 ==========================
 Fixes since v1.5.4.3
 --------------------
 * Building and installing with an overtight umask such as 077 made
   installed templates unreadable by others, while the rest of the install
   are done in a way that is friendly to umask 022.
 * "git cvsexportcommit -w $cvsdir" misbehaved when GIT_DIR is set to a
   relative directory.
 * "git http-push" had an invalid memory access that could lead it to
   segfault.
 * When "git rebase -i" gave control back to the user for a commit that is
   marked to be edited, it just said "modify it with commit --amend",
   without saying what to do to continue after modifying it.  Give an
   explicit instruction to run "rebase --continue" to be more helpful.
 * "git send-email" in 1.5.4.3 issued a bogus empty In-Reply-To: header.
 * "git bisect" showed mysterious "won't bisect on seeked tree" error message.
   This was leftover from Cogito days to prevent "bisect" starting from a
   cg-seeked state.  We still keep the Cogito safety, but running "git bisect
   start" when another bisect was in effect will clean up and start over.
 * "git push" with an explicit PATH to receive-pack did not quite work if
   receive-pack was not on usual PATH.  We earlier fixed the same issue
   with "git fetch" and upload-pack, but somehow forgot to do so in the
   other direction.
 * git-gui's info dialog was not displayed correctly when the user tries
   to commit nothing (i.e. without staging anything).
 * "git revert" did not properly fail when attempting to run with a
   dirty index.
 * "git merge --no-commit --no-ff <other>" incorrectly made commits.
 * "git merge --squash --no-ff <other>", which is a nonsense combination
   of options, was not rejected.
 * "git ls-remote" and "git remote show" against an empty repository
   failed, instead of just giving an empty result (regression).
 * "git fast-import" did not handle a renamed path whose name needs to be
   quoted, due to a bug in unquote_c_style() function.
 * "git cvsexportcommit" was confused when multiple files with the same
   basename needed to be pushed out in the same commit.
 * "git daemon" did not send early errors to syslog.
 * "git log --merge" did not work well with --left-right option.
 * "git svn" promprted for client cert password every time it accessed the
   server.
 * The reset command in "git fast-import" data stream was documented to
   end with an optional LF, but it actually required one.
 * "git svn dcommit/rebase" did not honor --rewrite-root option.
 Also included are a handful documentation updates.
--- a/Documentation/RelNotes-1.5.4.5.txt
+++ b/Documentation/RelNotes-1.5.4.5.txt
@ -1,56 +0,0 @@
 GIT v1.5.4.5 Release Notes
 ==========================
 Fixes since v1.5.4.4
 --------------------
 * "git fetch there" when the URL information came from the Cogito style
   branches/there file did not update refs/heads/there (regression in
   1.5.4).
 * Bogus refspec configuration such as "remote.there.fetch = =" were not
   detected as errors (regressionin 1.5.4).
 * You couldn't specify a custom editor whose path contains a whitespace
   via GIT_EDITOR (and core.editor).
 * The subdirectory filter to "git filter-branch" mishandled a history
   where the subdirectory becomes empty and then later becomes non-empty.
 * "git shortlog" gave an empty line if the original commit message was
   malformed (e.g. a botched import from foreign SCM).  Now it finds the
   first non-empty line and uses it for better information.
 * When the user fails to give a revision parameter to "git svn", an error
   from the Perl interpreter was issued because the script lacked proper
   error checking.
 * After "git rebase" stopped due to conflicts, if the user played with
   "git reset" and friends, "git rebase --abort" failed to go back to the
   correct commit.
 * Additional work trees prepared with git-new-workdir (in contrib/) did
   not share git-svn metadata directory .git/svn with the original.
 * "git-merge-recursive" did not mark addition of the same path with
   different filemodes correctly as a conflict.
 * "gitweb" gave malformed URL when pathinfo stype paths are in use.
 * "-n" stands for "--no-tags" again for "git fetch".
 * "git format-patch" did not detect the need to add 8-bit MIME header
   when the user used format.header configuration.
 * "rev~" revision specifier used to mean "rev", which was inconsistent
   with how "rev^" worked.  Now "rev~" is the same as "rev~1" (hence it
   also is the same as "rev^1"), and "rev~0" is the same as "rev^0"
   (i.e. it has to be a commit).
 * "git quiltimport" did not grok empty lines, lines in "file -pNNN"
   format to specify the prefix levels and lines with trailing comments.
 * "git rebase -m" triggered pre-commit verification, which made
   "rebase --continue" impossible.
 As usual, it also comes with many documentation fixes and clarifications.
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/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.
--- a/Documentation/RelNotes-1.5.5.txt
+++ b/Documentation/RelNotes-1.5.5.txt
@ -1,213 +0,0 @@
 GIT v1.5.5 Release Notes
 ========================
 Updates since v1.5.4
 --------------------
 (subsystems)
 * Comes with git-gui 0.9.3.
 (portability)
 * We shouldn't ask for BSD group ownership semantics by setting g+s bit
   on directories on older BSD systems that refuses chmod() by non root
   users.  BSD semantics is the default there anyway.
 * Bunch of portability improvement patches coming from an effort to port
   to Solaris has been applied.
 (performance)
 * On platforms with suboptimal qsort(3) implementation, there
   is an option to use more reasonable substitute we ship with
   our software.
 * New configuration variable "pack.packsizelimit" can be used
   in place of command line option --max-pack-size.
 * "git fetch" over the native git protocol used to make a
   connection to find out the set of current remote refs and
   another to actually download the pack data.  We now use only
   one connection for these tasks.
 * "git commit" does not run lstat(2) more than necessary
   anymore.
 (usability, bells and whistles)
 * Bash completion script (in contrib) are aware of more commands and
   options.
 * You can be warned when core.autocrlf conversion is applied in
   such a way that results in an irreversible conversion.
 * A catch-all "color.ui" configuration variable can be used to
   enable coloring of all color-capable commands, instead of
   individual ones such as "color.status" and "color.branch".
 * The commands refused to take absolute pathnames where they
   require pathnames relative to the work tree or the current
   subdirectory.  They now can take absolute pathnames in such a
   case as long as the pathnames do not refer outside of the
   work tree.  E.g. "git add $(pwd)/foo" now works.
 * Error messages used to be sent to stderr, only to get hidden,
   when $PAGER was in use.  They now are sent to stdout along
   with the command output to be shown in the $PAGER.
 * A pattern "foo/" in .gitignore file now matches a directory
   "foo".  Pattern "foo" also matches as before.
 * bash completion's prompt helper function can talk about
   operation in-progress (e.g. merge, rebase, etc.).
 * Configuration variables "url.<usethis>.insteadof = <otherurl>" can be
   used to tell "git-fetch" and "git-push" to use different URL than what
   is given from the command line.
 * "git add -i" behaves better even before you make an initial commit.
 * "git am" refused to run from a subdirectory without a good reason.
 * After "git apply --whitespace=fix" fixes whitespace errors in a patch,
   a line before the fix can appear as a context or preimage line in a
   later patch, causing the patch not to apply.  The command now knows to
   see through whitespace fixes done to context lines to successfully
   apply such a patch series.
 * "git branch" (and "git checkout -b") to branch from a local branch can
   optionally set "branch.<name>.merge" to mark the new branch to build on
   the other local branch, when "branch.autosetupmerge" is set to
   "always", or when passing the command line option "--track" (this option
   was ignored when branching from local branches).  By default, this does
   not happen when branching from a local branch.
 * "git checkout" to switch to a branch that has "branch.<name>.merge" set
   (i.e. marked to build on another branch) reports how much the branch
   and the other branch diverged.
 * When "git checkout" has to update a lot of paths, it used to be silent
   for 4 seconds before it showed any progress report.  It is now a bit
   more impatient and starts showing progress report early.
 * "git commit" learned a new hook "prepare-commit-msg" that can
   inspect what is going to be committed and prepare the commit
   log message template to be edited.
 * "git cvsimport" can now take more than one -M options.
 * "git describe" learned to limit the tags to be used for
   naming with --match option.
 * "git describe --contains" now barfs when the named commit
   cannot be described.
 * "git describe --exact-match" describes only commits that are tagged.
 * "git describe --long" describes a tagged commit as $tag-0-$sha1,
   instead of just showing the exact tagname.
 * "git describe" warns when using a tag whose name and path contradict
   with each other.
 * "git diff" learned "--relative" option to limit and output paths
   relative to the current directory when working in a subdirectory.
 * "git diff" learned "--dirstat" option to show birds-eye-summary of
   changes more concisely than "--diffstat".
 * "git format-patch" learned --cover-letter option to generate a cover
   letter template.
 * "git gc" learned --quiet option.
 * "git gc" now automatically prunes unreachable objects that are two
   weeks old or older.
 * "git gc --auto" can be disabled more easily by just setting gc.auto
   to zero.  It also tolerates more packfiles by default.
 * "git grep" now knows "--name-only" is a synonym for the "-l" option.
 * "git help <alias>" now reports "'git <alias>' is alias to <what>",
   instead of saying "No manual entry for git-<alias>".
 * "git help" can use different backends to show manual pages and this can
   be configured using "man.viewer" configuration.
 * "gitk" does not restore window position from $HOME/.gitk anymore (it
   still restores the size).
 * "git log --grep=<what>" learned "--fixed-strings" option to look for
   <what> without treating it as a regular expression.
 * "git gui" learned an auto-spell checking.
 * "git push <somewhere> HEAD" and "git push <somewhere> +HEAD" works as
   expected; they push the current branch (and only the current branch).
   In addition, HEAD can be written as the value of "remote.<there>.push"
   configuration variable.
 * When the configuration variable "pack.threads" is set to 0, "git
   repack" auto detects the number of CPUs and uses that many threads.
 * "git send-email" learned to prompt for passwords
   interactively.
 * "git send-email" learned an easier way to suppress CC
   recipients.
 * "git stash" learned "pop" command, that applies the latest stash and
   removes it from the stash, and "drop" command to discard the named
   stash entry.
 * "git submodule" learned a new subcommand "summary" to show the
   symmetric difference between the HEAD version and the work tree version
   of the submodule commits.
 * Various "git cvsimport", "git cvsexportcommit", "git svn" and
   "git p4" improvements.
 (internal)
 * Duplicated code between git-help and git-instaweb that
   launches user's preferred browser has been refactored.
 * It is now easier to write test scripts that records known
   breakages.
 * "git checkout" is rewritten in C.
 * "git remote" is rewritten in C.
 * Two conflict hunks that are separated by a very short span of common
   lines are now coalesced into one larger hunk, to make the result easier
   to read.
 * Run-command API's use of file descriptors is documented clearer and
   is more consistent now.
 * diff output can be sent to FILE * that is different from stdout.  This
   will help reimplementing more things in C.
 Fixes since v1.5.4
 ------------------
 All of the fixes in v1.5.4 maintenance series are included in
 this release, unless otherwise noted.
 * "git-http-push" did not allow deletion of remote ref with the usual
   "push <remote> :<branch>" syntax.
 * "git-rebase --abort" did not go back to the right location if
   "git-reset" was run during the "git-rebase" session.
 * "git imap-send" without setting imap.host did not error out but
   segfaulted.
 ---
 exec >/var/tmp/1
 O=v1.5.5-rc1-21-g319a36a
 echo O=`git describe refs/heads/master`
 git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@ -1,453 +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 (and only if) the patch
 	  is ready for inclusion. 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.  Use of additional markers after PATCH and
 the closing bracket to mark the nature of the patch is also
 encouraged.  E.g. [PATCH/RFC] is often used when the patch is
 not ready to be applied but it is for discussion, [PATCH v2],
 [PATCH v3] etc. are often seen when you are sending an update to
 what you have previously sent.
 "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 for
 inclusion.
 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.
 Notice that you can place your own Signed-off-by: line when
 forwarding somebody else's patch with the above rules for
 D-C-O.  Indeed you are encouraged to do so.  Do not forget to
 place an in-body "From: " line at the beginning to properly attribute
 the change to its true author (see (2) above).
 Some people also put extra tags at the end.
 "Acked-by:" says that the patch was reviewed by the person who
 is more familiar with the issues and the area the patch attempts
 to modify.  "Tested-by:" says the patch was tested by the person
 and found to have the desired effect.
 ------------------------------------------------
 An ideal patch flow
 Here is an ideal patch flow for this project the current maintainer
 suggests to the contributors:
 (0) You come up with an itch.  You code it up.
 (1) Send it to the list and cc people who may need to know about
     the change.
     The people who may need to know are the ones whose code you
     are butchering.  These people happen to be the ones who are
     most likely to be knowledgeable enough to help you, but
     they have no obligation to help you (i.e. you ask for help,
     don't demand).  "git log -p -- $area_you_are_modifying" would
     help you find out who they are.
 (2) You get comments and suggestions for improvements.  You may
     even get them in a "on top of your change" patch form.
 (3) Polish, refine, and re-send to the list and the people who
     spend their time to improve your patch.  Go back to step (2).
 (4) The list forms consensus that the last round of your patch is
     good.  Send it to the list and cc the maintainer.
 (5) A topic branch is created with the patch and is merged to 'next',
     and cooked further and eventually graduates to 'master'.
 In any time between the (2)-(3) cycle, the maintainer may pick it up
 from the list and queue it to 'pu', in order to make it easier for
 people play with it without having to pick up and apply the patch to
 their trees themselves.
 ------------------------------------------------
 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.
--- a/Documentation/asciidoc.conf
+++ b/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[]
--- a/Documentation/blame-options.txt
+++ b/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.
--- a/Documentation/build-docdep.perl
+++ b/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";
    }
 }
--- a/Documentation/callouts.xsl
+++ b/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>
--- a/Documentation/cat-texi.perl
+++ b/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";
--- a/Documentation/cmd-list.perl
+++ b/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";
 	}
 }
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
--- a/Documentation/cvs-migration.txt
+++ b/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.
--- a/Documentation/diff-format.txt
+++ b/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.
--- a/Documentation/diff-generate-patch.txt
+++ b/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").
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@ -1,232 +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.
 --relative[=<path>]::
 	When run from a subdirectory of the project, it can be
 	told to exclude changes outside the directory and show
 	pathnames relative to it with this option.  When you are
 	not in a subdirectory (e.g. in a bare repository), you
 	can name which subdirectory to make the output relative
 	to by giving a <path> as an argument.
 --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].
--- a/Documentation/diffcore.txt
+++ b/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
 ------------------------------------------------
--- a/Documentation/docbook-xsl.css
+++ b/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; }
 }
--- a/Documentation/docbook.xsl
+++ b/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>
--- a/Documentation/everyday.txt
+++ b/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.
--- a/Documentation/fetch-options.txt
+++ b/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.
--- a/Documentation/fix-texi.perl
+++ b/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;
 	}
 }
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@ -1,249 +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 in the
 	current directory and its subdirectories 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 - stage this hunk
       n - do not stage this hunk
       a - stage this and all the remaining hunks in the file
       d - do not stage this hunk nor any of the remaining hunks in the file
       j - leave this hunk undecided, see next undecided hunk
       J - leave this hunk undecided, see next hunk
       k - leave this hunk undecided, see previous undecided hunk
       K - leave this hunk undecided, see 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
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@ -1,156 +0,0 @@
 git-am(1)
 =========
 NAME
 ----
 git-am - Apply a series of patches from a mailbox
 SYNOPSIS
 --------
 [verse]
 'git-am' [--signoff] [--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.
 -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 -r .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
--- a/Documentation/git-annotate.txt
+++ b/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
--- a/Documentation/git-apply.txt
+++ b/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
--- a/Documentation/git-archimport.txt
+++ b/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
--- a/Documentation/git-archive.txt
+++ b/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
--- a/Documentation/git-bisect.txt
+++ b/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
--- a/Documentation/git-blame.txt
+++ b/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
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@ -1,189 +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
 the remote branch. This behavior may be changed via 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::
 	When creating a new branch, set up configuration so that git-pull
 	will automatically retrieve data from the start point, which must be
 	a branch. Use this if you always pull from the same upstream branch
 	into the new branch, and if you don't want to use "git pull
 	<repository> <refspec>" explicitly. This behavior is the default
 	when the start point is a remote branch. 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. Set it to `always` if you want this behavior when the
 	start-point is either a local or remote branch.
 --no-track::
 	Ignore 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
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@ -1,174 +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.
 To create the bundle you have to specify the basis. You have some options:
 - Without basis.
 +
 This is useful when sending the whole history.
 ------------
 $ git bundle create mybundle master
 ------------
 - Using temporally tags.
 +
 We set a tag in R1 (lastR2bundle) after the previous such transport,
 and move it afterwards to help build the bundle.
 ------------
 $ git-bundle create mybundle master ^lastR2bundle
 $ git tag -f lastR2bundle master
 ------------
 - Using a tag present in both repositories
 ------------
 $ git bundle create mybundle master ^v1.0.0
 ------------
 - A basis based on time.
 ------------
 $ git bundle create mybundle master --since=10.days.ago
 ------------
 - With a limit on the number of commits
 ------------
 $ git bundle create mybundle master -n 10
 ------------
 Then you move mybundle from A to B, and in R2 on B:
 ------------
 $ git-bundle verify mybundle
 $ git-fetch mybundle master:localRef
 ------------
 With something like this in the config in R2:
 ------------------------
 [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 on machine B:
 ------------
 $ 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
--- a/Documentation/git-cat-file.txt
+++ b/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
--- a/Documentation/git-check-attr.txt
+++ b/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
--- a/Documentation/git-check-ref-format.txt
+++ b/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
--- a/Documentation/git-checkout-index.txt
+++ b/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
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@ -1,218 +0,0 @@
 git-checkout(1)
 ===============
 NAME
 ----
 git-checkout - Checkout a branch or paths to the working tree
 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 creating a new branch, set up configuration so that git-pull
 	will automatically retrieve data from the start point, which must be
 	a branch. Use this if you always pull from the same upstream branch
 	into the new branch, and if you don't want to use "git pull
 	<repository> <refspec>" explicitly. This behavior is the default
 	when the start point is a remote branch. 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. Set it to `always` if you want this behavior when the
 	start-point is either a local or remote branch.
 --no-track::
 	Ignore 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
--- a/Documentation/git-cherry-pick.txt
+++ b/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 cherry-pick 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
--- a/Documentation/git-cherry.txt
+++ b/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
--- a/Documentation/git-citool.txt
+++ b/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
--- a/Documentation/git-clean.txt
+++ b/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
--- a/Documentation/git-clone.txt
+++ b/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
--- a/Documentation/git-commit-tree.txt
+++ b/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
--- a/Documentation/git-commit.txt
+++ b/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`, `prepare-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
--- a/Documentation/git-config.txt
+++ b/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
--- a/Documentation/git-count-objects.txt
+++ b/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
--- a/Documentation/git-cvsexportcommit.txt
+++ b/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
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@ -1,173 +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 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.
 +
 The regex must capture the source branch name in $1.
 +
 This option can be used several times to provide several detection regexes.
 -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
--- a/Documentation/git-cvsserver.txt
+++ b/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
--- a/Documentation/git-daemon.txt
+++ b/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
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@ -1,144 +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.
 	An <n> of 0 will cause only exact matches to be output.
 --exact-match::
 	Only output exact matches (a tag directly references the
 	supplied commit).  This is a synonym for --candidates=0.
 --debug::
 	Verbosely display information about the searching strategy
 	being employed to standard error.  The tag name will still
 	be printed to standard out.
 --long::
 	Always output the long format (the tag, the number of commits
 	and the abbreviated commit name) even when it matches a tag.
 	This is useful when you want to see parts of the commit object name
 	in "describe" output, even when the commit in question happens to be
 	a tagged version.  Instead of just emitting the tag name, it will
 	describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2
 	that points at object deadbeef....).
 --match <pattern>::
 	Only consider tags matching the given pattern (can be used to avoid
 	leaking private tags made from the repository).
 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
--- a/Documentation/git-diff-files.txt
+++ b/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
--- a/Documentation/git-diff-index.txt
+++ b/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
--- a/Documentation/git-diff-tree.txt
+++ b/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
--- a/Documentation/git-diff.txt
+++ b/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
--- a/Documentation/git-fast-export.txt
+++ b/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
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@ -1,102 +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] [--include-tag] [--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.
 \--include-tag::
 	If the remote side supports it, annotated tags objects will
 	be downloaded on the same connection as the other objects if
 	the object the tag references is downloaded.  The caller must
 	otherwise determine the tags this option made available.
 \--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
--- a/Show More
+++ b/Show More