git-gui: set version 0.21

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

.gitattributes

@@ -1,2 +1,4 @@
-* whitespace=!indent,trail,space
-*.[ch] whitespace
+*           whitespace=indent-with-non-tab,trailing-space,space-before-tab,tabwidth=4
+*           encoding=US-ASCII
+git-gui.sh  encoding=UTF-8
+/po/*.po    encoding=UTF-8

.gitignore

@@ -1,172 +1,8 @@
-GIT-BUILD-OPTIONS
-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]
+.DS_Store
 config.mak
-autom4te.cache
-config.cache
-config.log
-config.status
-config.mak.autogen
-config.mak.append
-configure
-tags
-TAGS
-cscope*
+Git Gui.app*
+git-gui.tcl
+GIT-VERSION-FILE
+GIT-GUI-VARS
+git-gui
+lib/tclIndex

.mailmap

@@ -1,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>

COPYING

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

Documentation/.gitattributes

@@ -1 +0,0 @@
-*.txt whitespace

Documentation/.gitignore

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

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).

Documentation/Makefile

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

Documentation/RelNotes-1.5.0.1.txt

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

Documentation/RelNotes-1.5.0.2.txt

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

Documentation/RelNotes-1.5.0.3.txt

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

Documentation/RelNotes-1.5.0.4.txt

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

Documentation/RelNotes-1.5.0.5.txt

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

Documentation/RelNotes-1.5.0.6.txt

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

Documentation/RelNotes-1.5.0.7.txt

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

Documentation/RelNotes-1.5.0.txt

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

Documentation/RelNotes-1.5.1.1.txt

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

Documentation/RelNotes-1.5.1.2.txt

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

Documentation/RelNotes-1.5.1.3.txt

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

Documentation/RelNotes-1.5.1.4.txt

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

Documentation/RelNotes-1.5.1.5.txt

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

Documentation/RelNotes-1.5.1.6.txt

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

Documentation/RelNotes-1.5.1.txt

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

Documentation/RelNotes-1.5.2.1.txt

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

Documentation/RelNotes-1.5.2.2.txt

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

Documentation/RelNotes-1.5.2.3.txt

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

Documentation/RelNotes-1.5.2.4.txt

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

Documentation/RelNotes-1.5.2.5.txt

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

Documentation/RelNotes-1.5.2.txt

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

Documentation/RelNotes-1.5.3.1.txt

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

Documentation/RelNotes-1.5.3.2.txt

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

Documentation/RelNotes-1.5.3.3.txt

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

Documentation/RelNotes-1.5.3.4.txt

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

Documentation/RelNotes-1.5.3.5.txt

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

Documentation/RelNotes-1.5.3.6.txt

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

Documentation/RelNotes-1.5.3.7.txt

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

Documentation/RelNotes-1.5.3.8.txt

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

Documentation/RelNotes-1.5.3.txt

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

Documentation/RelNotes-1.5.4.1.txt

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

Documentation/RelNotes-1.5.4.2.txt

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

Documentation/RelNotes-1.5.4.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.

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.

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.

Documentation/RelNotes-1.5.4.txt

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

Documentation/RelNotes-1.5.5.1.txt

@@ -1,44 +0,0 @@
-GIT v1.5.5.1 Release Notes
-==========================
-
-Fixes since v1.5.5
-------------------
-
- * "git archive --prefix=$path/" mishandled gitattributes.
-
- * "git fetch -v" that fetches into FETCH_HEAD did not report the summary
-   the same way as done for updating the tracking refs.
-
- * "git svn" misbehaved when the configuration file customized the "git
-   log" output format using format.pretty.
-
- * "git submodule status" leaked an unnecessary error message.
-
- * "git log --date-order --topo-order" did not override the earlier
-   date-order with topo-order as expected.
-
- * "git bisect good $this" did not check the validity of the revision
-   given properly.
-
- * "url.<there>.insteadOf" did not work correctly.
-
- * "git clean" ran inside subdirectory behaved as if the directory was
-   explicitly specified for removal by the end user from the top level.
-
- * "git bisect" from a detached head leaked an unnecessary error message.
-
- * "git bisect good $a $b" when $a is Ok but $b is bogus should have
-   atomically failed before marking $a as good.
-
- * "git fmt-merge-msg" did not clean up leading empty lines from commit
-   log messages like "git log" family does.
-
- * "git am" recorded a commit with empty Subject: line without
-   complaining.
-
- * when given a commit log message whose first paragraph consists of
-   multiple lines, "git rebase" squashed it into a single line.
-
- * "git remote add $bogus_name $url" did not complain properly.
-
-Also comes with various documentation updates.

Documentation/RelNotes-1.5.5.txt

@@ -1,207 +0,0 @@
-GIT v1.5.5 Release Notes
-========================
-
-Updates since v1.5.4
---------------------
-
-(subsystems)
-
- * Comes with git-gui 0.10.1
-
-(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 cvsserver",
-   "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.

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.

Documentation/asciidoc.conf

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

Documentation/blame-options.txt

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

Documentation/build-docdep.perl

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

Documentation/callouts.xsl

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

Documentation/cat-texi.perl

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

Documentation/cmd-list.perl

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

Documentation/cvs-migration.txt

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

Documentation/diff-format.txt

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

Documentation/diff-generate-patch.txt

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

Documentation/diff-options.txt

@@ -1,241 +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.
-
---dirstat[=limit]::
-	Output only the sub-directories that are impacted by a diff,
-	and to what degree they are impacted.  You can override the
-	default cut-off in percent (3) by "--dirstat=limit".  If you
-	want to enable "cumulative" directory statistics, you can use
-	the "--cumulative" flag, which adds up percentages recursively
-	even when they have been already reported for a sub-directory.
-
---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. See the description
-	of the `--diff-filter` option on what the status letters mean.
-
---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].

Documentation/diffcore.txt

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

Documentation/docbook-xsl.css

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

Documentation/docbook.xsl

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

Documentation/everyday.txt

@@ -1,456 +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.
-
-Repack a small project into single pack.::
-+
-------------
-$ git gc <1>
-------------
-+
-<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 <7>
-$ git fetch --tags <8>
-------------
-+
-<1> repeat as needed.
-<2> extract patches from your branch for e-mail submission.
-<3> `git pull` fetches from `origin` by default and merges into the
-current branch.
-<4> immediately after pulling, look at the changes done upstream
-since last time we checked, only in the
-area we are interested in.
-<5> fetch from a specific branch from a specific repository and merge.
-<6> revert the pull.
-<7> garbage collect leftover objects from reverted pull.
-<8> from time to time, obtain official tags from the `origin`
-and store them under `.git/refs/tags/`.
-
-
-Push into another repository.::
-+
-------------
-satellite$ git clone mothership:frotz frotz <1>
-satellite$ cd frotz
-satellite$ git config --get-regexp '^(remote|branch)\.' <2>
-remote.origin.url mothership:frotz
-remote.origin.fetch refs/heads/*:refs/remotes/origin/*
-branch.master.remote origin
-branch.master.merge refs/heads/master
-satellite$ git config remote.origin.push \
-           master:refs/remotes/satellite/master <3>
-satellite$ edit/compile/test/commit
-satellite$ git push origin <4>
-
-mothership$ cd frotz
-mothership$ git checkout master
-mothership$ git merge satellite/master <5>
-------------
-+
-<1> mothership machine has a frotz repository under your home
-directory; clone from it to start a repository on the satellite
-machine.
-<2> clone sets these configuration variables by default.
-It arranges `git pull` to fetch and store the branches of mothership
-machine to local `remotes/origin/*` tracking branches.
-<3> arrange `git push` to push local `master` branch to
-`remotes/satellite/master` branch of the mothership machine.
-<4> push will stash our work away on `remotes/satellite/master`
-tracking branch on the mothership machine.  You could use this as
-a back-up method.
-<5> on mothership machine, merge the work done on the satellite
-machine into the master branch.
-
-Branch off of a specific tag.::
-+
-------------
-$ git checkout -b private2.6.14 v2.6.14 <1>
-$ edit/compile/test; git commit -a
-$ git checkout master
-$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
-  git am -3 -k <2>
-------------
-+
-<1> create a private branch based on a well known (but somewhat behind)
-tag.
-<2> forward port all changes in `private2.6.14` branch to `master` branch
-without a formal "merging".
-
-
-Integrator[[Integrator]]
-------------------------
-
-A fairly central person acting as the integrator in a group
-project receives changes made by others, reviews and integrates
-them and publishes the result for others to use, using these
-commands in addition to the ones needed by participants.
-
-  * linkgit:git-am[1] to apply patches e-mailed in from your
-    contributors.
-
-  * linkgit:git-pull[1] to merge from your trusted lieutenants.
-
-  * linkgit:git-format-patch[1] to prepare and send suggested
-    alternative to contributors.
-
-  * linkgit:git-revert[1] to undo botched commits.
-
-  * linkgit:git-push[1] to publish the bleeding edge.
-
-
-Examples
-~~~~~~~~
-
-My typical GIT day.::
-+
-------------
-$ git status <1>
-$ git show-branch <2>
-$ mailx <3>
-& s 2 3 4 5 ./+to-apply
-& s 7 8 ./+hold-linus
-& q
-$ git checkout -b topic/one master
-$ git am -3 -i -s -u ./+to-apply <4>
-$ compile/test
-$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>
-$ git checkout topic/one && git rebase master <6>
-$ git checkout pu && git reset --hard next <7>
-$ git merge topic/one topic/two && git merge hold/linus <8>
-$ git checkout maint
-$ git cherry-pick master~4 <9>
-$ compile/test
-$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
-$ git fetch ko && git show-branch master maint 'tags/ko-*' <11>
-$ git push ko <12>
-$ git push ko v0.99.9x <13>
-------------
-+
-<1> see what I was in the middle of doing, if any.
-<2> see what topic branches I have and think about how ready
-they are.
-<3> read mails, save ones that are applicable, and save others
-that are not quite ready.
-<4> apply them, interactively, with my sign-offs.
-<5> create topic branch as needed and apply, again with my
-sign-offs.
-<6> rebase internal topic branch that has not been merged to the
-master, nor exposed as a part of a stable branch.
-<7> restart `pu` every time from the next.
-<8> and bundle topic branches still cooking.
-<9> backport a critical fix.
-<10> create a signed tag.
-<11> make sure I did not accidentally rewind master beyond what I
-already pushed out.  `ko` shorthand points at the repository I have
-at kernel.org, and looks like this:
-+
-------------
-$ cat .git/remotes/ko
-URL: kernel.org:/pub/scm/git/git.git
-Pull: master:refs/tags/ko-master
-Pull: next:refs/tags/ko-next
-Pull: maint:refs/tags/ko-maint
-Push: master
-Push: next
-Push: +pu
-Push: maint
-------------
-+
-In the output from `git show-branch`, `master` should have
-everything `ko-master` has, and `next` should have
-everything `ko-next` has.
-
-<12> push out the bleeding edge.
-<13> push the tag out, too.
-
-
-Repository Administration[[Repository Administration]]
-------------------------------------------------------
-
-A repository administrator uses the following tools to set up
-and maintain access to the repository by developers.
-
-  * linkgit:git-daemon[1] to allow anonymous download from
-    repository.
-
-  * linkgit:git-shell[1] can be used as a 'restricted login shell'
-    for shared central repository users.
-
-link:howto/update-hook-example.txt[update hook howto] has a good
-example of managing a shared central repository.
-
-
-Examples
-~~~~~~~~
-We assume the following in /etc/services::
-+
-------------
-$ grep 9418 /etc/services
-git		9418/tcp		# Git Version Control System
-------------
-
-Run git-daemon to serve /pub/scm from inetd.::
-+
-------------
-$ grep git /etc/inetd.conf
-git	stream	tcp	nowait	nobody \
-  /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
-------------
-+
-The actual configuration line should be on one line.
-
-Run git-daemon to serve /pub/scm from xinetd.::
-+
-------------
-$ cat /etc/xinetd.d/git-daemon
-# default: off
-# description: The git server offers access to git repositories
-service git
-{
-        disable = no
-        type            = UNLISTED
-        port            = 9418
-        socket_type     = stream
-        wait            = no
-        user            = nobody
-        server          = /usr/bin/git-daemon
-        server_args     = --inetd --export-all --base-path=/pub/scm
-        log_on_failure  += USERID
-}
-------------
-+
-Check your xinetd(8) documentation and setup, this is from a Fedora system.
-Others might be different.
-
-Give push/pull only access to developers.::
-+
-------------
-$ grep git /etc/passwd <1>
-alice:x:1000:1000::/home/alice:/usr/bin/git-shell
-bob:x:1001:1001::/home/bob:/usr/bin/git-shell
-cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
-david:x:1003:1003::/home/david:/usr/bin/git-shell
-$ grep git /etc/shells <2>
-/usr/bin/git-shell
-------------
-+
-<1> log-in shell is set to /usr/bin/git-shell, which does not
-allow anything but `git push` and `git pull`.  The users should
-get an ssh access to the machine.
-<2> in many distributions /etc/shells needs to list what is used
-as the login shell.
-
-CVS-style shared repository.::
-+
-------------
-$ grep git /etc/group <1>
-git:x:9418:alice,bob,cindy,david
-$ cd /home/devo.git
-$ ls -l <2>
-  lrwxrwxrwx   1 david git    17 Dec  4 22:40 HEAD -> refs/heads/master
-  drwxrwsr-x   2 david git  4096 Dec  4 22:40 branches
-  -rw-rw-r--   1 david git    84 Dec  4 22:40 config
-  -rw-rw-r--   1 david git    58 Dec  4 22:40 description
-  drwxrwsr-x   2 david git  4096 Dec  4 22:40 hooks
-  -rw-rw-r--   1 david git 37504 Dec  4 22:40 index
-  drwxrwsr-x   2 david git  4096 Dec  4 22:40 info
-  drwxrwsr-x   4 david git  4096 Dec  4 22:40 objects
-  drwxrwsr-x   4 david git  4096 Nov  7 14:58 refs
-  drwxrwsr-x   2 david git  4096 Dec  4 22:40 remotes
-$ ls -l hooks/update <3>
-  -r-xr-xr-x   1 david git  3536 Dec  4 22:40 update
-$ cat info/allowed-users <4>
-refs/heads/master	alice\|cindy
-refs/heads/doc-update	bob
-refs/tags/v[0-9]*	david
-------------
-+
-<1> place the developers into the same git group.
-<2> and make the shared repository writable by the group.
-<3> use update-hook example by Carl from Documentation/howto/
-for branch policy control.
-<4> alice and cindy can push into master, only bob can push into doc-update.
-david is the release manager and is the only person who can
-create and push version tags.
-
-HTTP server to support dumb protocol transfer.::
-+
-------------
-dev$ git update-server-info <1>
-dev$ ftp user@isp.example.com <2>
-ftp> cp -r .git /home/user/myproject.git
-------------
-+
-<1> make sure your info/refs and objects/info/packs are up-to-date
-<2> upload to public HTTP server hosted by your ISP.

Documentation/fetch-options.txt

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

Documentation/fix-texi.perl

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

Documentation/git-add.txt

@@ -1,257 +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, staging modified
-	content for commit and marking deleted files for removal. 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).
-
-Bugs
-----
-The interactive mode does not work with files whose names contain
-characters that need C-quoting.  `core.quotepath` configuration can be
-used to work this limitation around to some degree, but backslash,
-double-quote and control characters will still have problems.
-
-See Also
---------
-linkgit:git-status[1]
-linkgit:git-rm[1]
-linkgit:git-reset[1]
-linkgit:git-mv[1]
-linkgit:git-commit[1]
-linkgit:git-update-index[1]
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-am.txt

@@ -1,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

Documentation/git-annotate.txt

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

Documentation/git-apply.txt

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

Documentation/git-archimport.txt

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

Documentation/git-archive.txt

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

Documentation/git-bisect.txt

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

Documentation/git-blame.txt

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

Documentation/git-branch.txt

@@ -1,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

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

Documentation/git-cat-file.txt

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

Documentation/git-check-attr.txt

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

Documentation/git-check-ref-format.txt

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

Documentation/git-checkout-index.txt

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

Documentation/git-checkout.txt

@@ -1,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

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

Documentation/git-cherry.txt

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

Documentation/git-citool.txt

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

Documentation/git-clean.txt

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

Documentation/git-clone.txt

@@ -1,208 +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 and then delete branches (or use any
-other git command that makes any existing commit unreferenced) in the
-source repository, some objects may become unreferenced (or dangling).
-These objects may be removed by normal git operations (such as git-commit[1])
-which automatically call git-gc[1]. If these objects are removed and
-were referenced by the cloned repository, then the cloned repository
-will become corrupt.
-
-
-
---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.
-+
-*NOTE*: see NOTE to --shared option.
-
---quiet::
--q::
-	Operate quietly.  This flag is passed to "rsync" and
-	"git-fetch-pack" commands when given.
-
---no-checkout::
--n::
-	No checkout of HEAD is performed after the clone is complete.
-
---bare::
-	Make a 'bare' GIT repository.  That is, instead of
-	creating `<directory>` and placing the administrative
-	files in `<directory>/.git`, make the `<directory>`
-	itself the `$GIT_DIR`. This obviously implies the `-n`
-	because there is nowhere to check out the working tree.
-	Also the branch heads at the remote are copied directly
-	to corresponding local branch heads, without mapping
-	them to `refs/remotes/origin/`.  When this option is
-	used, neither remote-tracking branches nor the related
-	configuration variables are created.
-
---origin <name>::
--o <name>::
-	Instead of using the remote name 'origin' to keep track
-	of the upstream repository, use <name> instead.
-
---upload-pack <upload-pack>::
--u <upload-pack>::
-	When given, and the repository to clone from is handled
-	by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
-	the command to specify non-default path for the command
-	run on the other end.
-
---template=<template_directory>::
-	Specify the directory from which templates will be used;
-	if unset the templates are taken from the installation
-	defined default, typically `/usr/share/git-core/templates`.
-
---depth <depth>::
-	Create a 'shallow' clone with a history truncated to the
-	specified number of revisions.  A shallow repository has a
-	number of limitations (you cannot clone or fetch from
-	it, nor push from nor into it), but is adequate if you
-	are only interested in the recent history of a large project
-	with a long history, and would want to send in fixes
-	as patches.
-
-<repository>::
-	The (possibly remote) repository to clone from.  See the
-	<<URLS,URLS>> section below for more information on specifying
-	repositories.
-
-<directory>::
-	The name of a new directory to clone into.  The "humanish"
-	part of the source repository is used if no directory is
-	explicitly given ("repo" for "/path/to/repo.git" and "foo"
-	for "host.xz:foo/.git").  Cloning into an existing directory
-	is not allowed.
-
-:git-clone: 1
-include::urls.txt[]
-
-Examples
---------
-
-Clone from upstream::
-+
-------------
-$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
-$ cd my2.6
-$ make
-------------
-
-
-Make a local clone that borrows from the current directory, without checking things out::
-+
-------------
-$ git clone -l -s -n . ../copy
-$ cd ../copy
-$ git show-branch
-------------
-
-
-Clone from upstream while borrowing from an existing local directory::
-+
-------------
-$ git clone --reference my2.6 \
-	git://git.kernel.org/pub/scm/.../linux-2.7 \
-	my2.7
-$ cd my2.7
-------------
-
-
-Create a bare repository to publish your changes to the public::
-+
-------------
-$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
-------------
-
-
-Create a repository on the kernel.org machine that borrows from Linus::
-+
-------------
-$ git clone --bare -l -s /pub/scm/.../torvalds/linux-2.6.git \
-    /pub/scm/.../me/subsys-2.6.git
-------------
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-commit-tree.txt

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

Documentation/git-commit.txt

@@ -1,315 +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.
-
--o|--only::
-	Make a commit only from the paths specified on the
-	command line, disregarding any contents that have been
-	staged so far. This is the default mode of operation of
-	'git commit' if any paths are given on the command line,
-	in which case this option can be omitted.
-	If this option is specified together with '--amend', then
-	no paths need be specified, which can be used to amend
-	the last commit without committing changes that have
-	already been staged.
-
--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

Documentation/git-config.txt

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

Documentation/git-count-objects.txt

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

Documentation/git-cvsexportcommit.txt

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

Documentation/git-cvsimport.txt

@@ -1,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

Documentation/git-cvsserver.txt

@@ -1,333 +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.  SSH users restricted to git-shell don't need to override the default
-with CVS_SERVER (and shouldn't) as git-shell understands `cvs` to mean
-git-cvsserver and pretends that the other end runs the real cvs better.
---
-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. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command,
-   automatically saving it in your 'CVS/Root' files, then you need to set them
-   explicitly in your environment.  CVSROOT should be set as per normal, but the
-   directory should point at the appropriate git repo.  As above, for SSH clients
-   _not_ restricted to git-shell, CVS_SERVER should be set to git-cvsserver.
-+
---
-------
-     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 server-side
-   .ssh/environment files (or .bashrc, etc., according to their specific shell)
-   export appropriate values for GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL,
-   GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL.  For SSH clients whose login
-   shell is bash, .bashrc may be a reasonable alternative.
-
-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.  This also sets the
-   name of your newly checked-out directory, unless you tell it otherwise with
-   `-d <dir_name>`.  For example, this checks out 'master' branch to the
-   `project-master` directory:
-+
-------
-     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.
-
-gitcvs.dbTableNamePrefix::
-	Database table name prefix.  Supports variable substitution
-	(see below).  Any non-alphabetic characters will be replaced
-	with underscores.
-
-All variables can also be set per access method, see <<configaccessmethod,above>>.
-
-Variable substitution
-^^^^^^^^^^^^^^^^^^^^^
-In `dbdriver` and `dbuser` you can use the following variables:
-
-%G::
-	git directory name
-%g::
-	git directory name, where all characters except for
-	alpha-numeric ones, `.`, and `-` are replaced with
-	`_` (this should make it easier to use the directory
-	name in a filename if wanted)
-%m::
-	CVS module/git head name
-%a::
-	access method (one of "ext" or "pserver")
-%u::
-	Name of the user running git-cvsserver.
-	If no name can be determined, the
-	numeric uid is used.
-
-Eclipse CVS Client Notes
-------------------------
-
-To get a checkout with the Eclipse CVS client:
-
-1. Select "Create a new project -> From CVS checkout"
-2. Create a new location. See the notes below for details on how to choose the
-   right protocol.
-3. Browse the 'modules' available. It will give you a list of the heads in
-   the repository. You will not be able to browse the tree from there. Only
-   the heads.
-4. Pick 'HEAD' when it asks what branch/tag to check out. Untick the
-   "launch commit wizard" to avoid committing the .project file.
-
-Protocol notes: If you are using anonymous access via pserver, just select that.
-Those using SSH access should choose the 'ext' protocol, and configure 'ext'
-access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
-'git-cvsserver'. Note that password support is not good when using 'ext',
-you will definitely want to have SSH keys setup.
-
-Alternatively, you can just use the non-standard extssh protocol that Eclipse
-offer. In that case CVS_SERVER is ignored, and you will have to replace
-the cvs utility on the server with git-cvsserver or manipulate your `.bashrc`
-so that calling 'cvs' effectively calls git-cvsserver.
-
-Clients known to work
----------------------
-
-- CVS 1.12.9 on Debian
-- CVS 1.11.17 on MacOSX (from Fink package)
-- Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
-- TortoiseCVS
-
-Operations supported
---------------------
-
-All the operations required for normal use are supported, including
-checkout, diff, status, update, log, add, remove, commit.
-Legacy monitoring operations are not supported (edit, watch and related).
-Exports and tagging (tags and branches) are not supported at this stage.
-
-The server should set the '-k' mode to binary when relevant, however,
-this is not really implemented yet. For now, you can force the server
-to set '-kb' for all files by setting the `gitcvs.allbinary` config
-variable. In proper GIT tradition, the contents of the files are
-always respected. No keyword expansion or newline munging is supported.
-
-Dependencies
-------------
-
-git-cvsserver depends on DBD::SQLite.
-
-Copyright and Authors
----------------------
-
-This program is copyright The Open University UK - 2006.
-
-Authors:
-
-- Martyn Smith    <martyn@catalyst.net.nz>
-- Martin Langhoff <martin@catalyst.net.nz>
-
-with ideas and patches from participants of the git-list <git@vger.kernel.org>.
-
-Documentation
---------------
-Documentation by Martyn Smith <martyn@catalyst.net.nz>, Martin Langhoff <martin@catalyst.net.nz>, and Matthias Urlichs <smurf@smurf.noris.de>.
-
-GIT
----
-Part of the linkgit:git[7] suite

Documentation/git-daemon.txt

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

Documentation/git-describe.txt

@@ -1,145 +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.  If the tag points to the commit, then only the tag is
-shown.  Otherwise, it suffixes the tag name with the number of
-additional commits on top of the tagged object and the
-abbreviated object name of the most recent 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

Documentation/git-diff-files.txt

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

Documentation/git-diff-index.txt

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

Documentation/git-diff-tree.txt

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

Documentation/git-diff.txt

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

Documentation/git-fast-export.txt

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