GIT 1.2.0

Signed-off-by: Junio C Hamano <junkio@cox.net>

.gitignore

@@ -1,3 +1,4 @@
+GIT-VERSION-FILE
 git
 git-add
 git-am
@@ -27,6 +28,7 @@ git-diff-files
 git-diff-index
 git-diff-stages
 git-diff-tree
+git-describe
 git-fetch
 git-fetch-pack
 git-findtags
@@ -60,7 +62,6 @@ git-merge-stupid
 git-mktag
 git-name-rev
 git-mv
-git-octopus
 git-pack-redundant
 git-pack-objects
 git-parse-remote
@@ -75,7 +76,9 @@ git-rebase
 git-receive-pack
 git-relink
 git-repack
+git-repo-config
 git-request-pull
+git-rerere
 git-reset
 git-resolve
 git-rev-list
@@ -86,6 +89,7 @@ git-send-pack
 git-sh-setup
 git-shell
 git-shortlog
+git-show
 git-show-branch
 git-show-index
 git-ssh-fetch
@@ -119,3 +123,5 @@ git-core.spec
 *.exe
 libgit.a
 *.o
+*.py[co]
+config.mak

Documentation/.gitignore

@@ -4,3 +4,4 @@
 *.7
 howto-index.txt
 doc.dep
+README

Documentation/Makefile

@@ -4,11 +4,13 @@ MAN7_TXT=git.txt
 DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
 
 ARTICLES = tutorial
+ARTICLES += core-tutorial
 ARTICLES += cvs-migration
 ARTICLES += diffcore
 ARTICLES += howto-index
 ARTICLES += repository-layout
 ARTICLES += hooks
+ARTICLES += everyday
 # with their own formatting rules.
 SP_ARTICLES = glossary howto/revert-branch-rebase
 
@@ -60,11 +62,14 @@ doc.dep : $(wildcard *.txt) build-docdep.perl
 
 -include doc.dep
 
-git.7: ../README
+git.7: README
+
+README: ../README
+	cp $< $@
 
 
 clean:
-	rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep
+	rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README
 
 %.html : %.txt
 	asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
@@ -75,7 +80,7 @@ clean:
 %.xml : %.txt
 	asciidoc -b docbook -d manpage -f asciidoc.conf $<
 
-git.html: git.txt ../README
+git.html: git.txt README
 
 glossary.html : glossary.txt sort_glossary.pl
 	cat $< | \

Documentation/cvs-migration.txt

@@ -1,126 +1,182 @@
 git for CVS users
 =================
 
-Ok, so you're a CVS user. That's ok, it's a treatable condition, and the
-first step to recovery is admitting you have a problem. The fact that
-you are reading this file means that you may be well on that path
-already.
+So you're a CVS user. That's ok, it's a treatable condition.  The job of
+this document is to put you on the road to recovery, by helping you
+convert an existing cvs repository to git, and by showing you how to use a
+git repository in a cvs-like fashion.
 
-The thing about CVS is that it absolutely sucks as a source control
-manager, and you'll thus be happy with almost anything else. git,
-however, may be a bit 'too' different (read: "good") for your taste, and
-does a lot of things differently. 
+Some basic familiarity with git is required.  This
+link:tutorial.html[tutorial introduction to git] should be sufficient.
 
-One particular suckage of CVS is very hard to work around: CVS is
-basically a tool for tracking 'file' history, while git is a tool for
-tracking 'project' history.  This sometimes causes problems if you are
-used to doing very strange things in CVS, in particular if you're doing
-things like making branches of just a subset of the project.  git can't
-track that, since git never tracks things on the level of an individual
-file, only on the whole project level. 
+First, note some ways that git differs from CVS:
 
-The good news is that most people don't do that, and in fact most sane
-people think it's a bug in CVS that makes it tag (and check in changes)
-one file at a time.  So most projects you'll ever see will use CVS
-'as if' it was sane.  In which case you'll find it very easy indeed to
-move over to git. 
+  * Commits are atomic and project-wide, not per-file as in CVS.
 
-First off: this is not a git tutorial. See
-link:tutorial.html[Documentation/tutorial.txt] for how git
-actually works. This is more of a random collection of gotcha's
-and notes on converting from CVS to git.
+  * Offline work is supported: you can make multiple commits locally,
+    then submit them when you're ready.
 
-Second: CVS has the notion of a "repository" as opposed to the thing
-that you're actually working in (your working directory, or your
-"checked out tree").  git does not have that notion at all, and all git
-working directories 'are' the repositories.  However, you can easily
-emulate the CVS model by having one special "global repository", which
-people can synchronize with.  See details later, but in the meantime
-just keep in mind that with git, every checked out working tree will
-have a full revision control history of its own.
+  * Branching is fast and easy.
 
+  * 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; see below
+    for details.
 
 Importing a CVS archive
 -----------------------
 
-Ok, you have an old project, and you want to at least give git a chance
-to see how it performs. The first thing you want to do (after you've
-gone through the git tutorial, and generally familiarized yourself with
-how to commit stuff etc in git) is to create a git'ified version of your
-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.  The magic command line is then
 
-Happily, that's very easy indeed. git will do it for you, although git
-will need the help of a program called "cvsps":
+-------------------------------------------
+$ git cvsimport -v -d <cvsroot> -C <destination> <module>
+-------------------------------------------
 
-	http://www.cobite.com/cvsps/
+This puts a git archive of the named CVS module in the directory
+<destination>, which will be created if necessary.  The -v option makes
+the conversion script very chatty.
 
-which is not actually related to git at all, but which makes CVS usage
-look almost sane (ie you almost certainly want to have it even if you
-decide to stay with CVS). However, git will want 'at least' version 2.1
-of cvsps (available at the address above), and in fact will currently
-refuse to work with anything else.
+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.
 
-Once you've gotten (and installed) cvsps, you may or may not want to get
-any more familiar with it, but make sure it is in your path. After that,
-the magic command line is
+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.
 
-	git cvsimport -v -d <cvsroot> -C <destination> <module>
+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.
 
-which will do exactly what you'd think it does: it will create a git
-archive of the named CVS module. The new archive will be created in the
-subdirectory named <destination>; it'll be created if it doesn't exist.
-Default is the local directory.
+Development Models
+------------------
 
-It can take some time to actually do the conversion for a large archive
-since it involves checking out from CVS every revision of every file,
-and the conversion script is reasonably chatty unless you omit the '-v'
-option, but on some not very scientific tests it averaged about twenty
-revisions per second, so a medium-sized project should not take more
-than a couple of minutes.  For larger projects or remote repositories,
-the process may take longer.
+CVS users are accustomed to giving a group of developers commit access to
+a common repository.  In the next section we'll explain how to do this
+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.
 
-After the (initial) import is done, the CVS archive's current head
-revision will be checked out -- thus, you can start adding your own
-changes right away.
+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.
 
-The import is incremental, i.e. if you call it again next month it'll
-fetch any CVS updates that have been happening in the meantime. The
-cut-off is date-based, so don't change the branches that were imported
-from CVS.
+With a small group, developers may just pull changes from each other's
+repositories without the need for a central maintainer.
 
-You can merge those updates (or, in fact, a different CVS branch) into
-your main branch:
+Emulating the CVS Development Model
+-----------------------------------
 
-	git resolve HEAD origin "merge with current CVS HEAD"
+Start with an ordinary git working directory containing the project, and
+remove the checked-out files, keeping just the bare .git directory:
 
-The HEAD revision from CVS is named "origin", not "HEAD", because git
-already uses "HEAD". (If you don't like 'origin', use cvsimport's
-'-o' option to change it.)
+------------------------------------------------
+$ mv project/.git /pub/repo.git
+$ rm -r project/
+------------------------------------------------
 
+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 gitlink:git-shell[1].
 
-Emulating CVS behaviour
------------------------
+Put all the committers should in the same group, and make the repository
+writable by that group:
 
+------------------------------------------------
+$ chgrp -R $group repo.git
+$ find repo.git -mindepth 1 -type d |xargs chmod ug+rwx,g+s
+$ GIT_DIR=repo.git git repo-config core.sharedrepository true
+------------------------------------------------
 
-So, by now you are convinced you absolutely want to work with git, but
-at the same time you absolutely have to have a central repository.
-Step back and think again. Okay, you still need a single central
-repository? There are several ways to go about that:
+Make sure committers have a umask of at most 027, so that the directories
+they create are writable and searchable by other group members.
 
-1. Designate a person responsible to pull all branches. Make the
-repository of this person public, and make every team member
-pull regularly from it.
+Suppose this repository is now set up in /pub/repo.git on the host
+foo.com.  Then as an individual commiter you can clone the shared
+repository:
 
-2. Set up a public repository with read/write access for every team
-member. Use "git pull/push" as you used "cvs update/commit".  Be
-sure that your repository is up to date before pushing, just
-like you used to do with "cvs commit"; your push will fail if
-what you are pushing is not up to date.
+------------------------------------------------
+$ git clone foo.com:/pub/repo.git/ my-project
+$ cd my-project
+------------------------------------------------
 
-3. Make the repository of every team member public. It is the
-responsibility of each single member to pull from every other
-team member.
+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.
+
+[NOTE]
+================================
+The first `git clone` places the following in the
+`my-project/.git/remotes/origin` file, and that's why the previous step
+and the next step both work.
+------------
+URL: foo.com:/pub/project.git/ my-project
+Pull: master:origin
+------------
+================================
+
+You can update the shared repository with your changes using:
+
+------------------------------------------------
+$ git push origin master
+------------------------------------------------
+
+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 repo.shared.xz:/pub/scm/project.git/
+------------
+
+as long as the shared repository does not have any branches
+other than `master`.
+
+[NOTE]
+============
+Because of this behaviour, if the shared repository and the developer's
+repository both have branches named `origin`, then a push like the above
+attempts to update the `origin` branch in the shared repository from the
+developer's `origin` branch.  The results may be unexpected, so it's
+usually best to remove any branch named `origin` from the shared
+repository.
+============
+
+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.txt[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].
 
 CVS annotate
 ------------
@@ -138,7 +194,7 @@ mailing list archives for details).
 git has a couple of alternatives, though, that you may find sufficient
 or even superior depending on your use.  One is called "git-whatchanged"
 (for obvious reasons) and the other one is called "pickaxe" ("a tool for
-the software archeologist"). 
+the software archaeologist"). 
 
 The "git-whatchanged" script is a truly trivial script that can give you
 a good overview of what has changed in a file or a directory (or an
@@ -187,7 +243,8 @@ you would use git-rev-list and git-diff-tree like this:
 
 We have already talked about the "\--stdin" form of git-diff-tree
 command that reads the list of commits and compares each commit
-with its parents.  The git-whatchanged command internally runs
+with its parents (otherwise you should go back and read the tutorial).
+The git-whatchanged command internally runs
 the equivalent of the above command, and can be used like this:
 
 	$ git-whatchanged -p -S'if (frotz) {

Documentation/diff-format.txt

@@ -117,7 +117,7 @@ git specific extension to diff format
 What -p option produces is slightly different from the
 traditional diff format.
 
-1.   It is preceeded with a "git diff" header, that looks like
+1.   It is preceded with a "git diff" header, that looks like
      this:
 
      diff --git a/file1 b/file2
@@ -146,3 +146,52 @@ the file that rename/copy produces, respectively.
 
 3.  TAB, LF, and backslash characters in pathnames are
     represented as `\t`, `\n`, and `\\`, respectively.
+
+
+combined diff format
+--------------------
+
+git-diff-tree and git-diff-files can take '-c' or '--cc' option
+to produce 'combined diff', which looks like this:
+
+------------
+diff --combined describe.c
+@@@ +98,7 @@@
+   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;
+------------
+
+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 last file.  A `+` character
+in the column N means that the line appears in the last file,
+and fileN does not have that line.
+
+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

@@ -18,6 +18,14 @@
 	object name of pre- and post-image blob on the "index"
 	line when generating a patch format output.	
 
+--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.
 
@@ -27,6 +35,17 @@
 -C::
 	Detect copies as well as renames.
 
+--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 

Documentation/everyday.txt

@@ -0,0 +1,441 @@
+Everyday GIT With 20 Commands Or So
+===================================
+
+GIT suite has over 100 commands, and the manual page for each of
+them discusses what the command does and how it is used in
+detail, but until you know what command should be used in order
+to achieve what you want to do, you cannot tell which manual
+page to look at, and if you know that already you do not need
+the manual.
+
+Does that mean you need to know all of them before you can use
+git?  Not at all.  Depending on the role you play, the set of
+commands you need to know is slightly different, but in any case
+what you need to learn is far smaller than the full set of
+commands to carry out your day-to-day work.  This document is to
+serve as a cheat-sheet and a set of pointers for people playing
+various roles.
+
+<<Basic Repository>> commands are needed by people who has 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
+<<Individual Developer (Participant)>> section as well.
+
+People who play <<Integrator>> role need to learn some more
+commands in addition to the above.
+
+<<Repository Administration>> commands are for system
+administrators who are responsible to care and feed git
+repositories to support developers.
+
+
+Basic Repository[[Basic Repository]]
+------------------------------------
+
+Everybody uses these commands to feed and care git repositories.
+
+  * gitlink:git-init-db[1] or gitlink:git-clone[1] to create a
+    new repository.
+
+  * gitlink:git-fsck-objects[1] to validate the repository.
+
+  * gitlink:git-prune[1] to garbage collect crufts in the
+    repository.
+
+  * gitlink:git-repack[1] to pack loose objects for efficiency.
+
+Examples
+~~~~~~~~
+
+Check health and remove cruft.::
++
+------------
+$ git fsck-objects <1>
+$ git prune
+$ git count-objects <2>
+$ git repack <3>
+$ git prune <4>
+
+<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
+diskspace is wasted by not repacking.
+<3> without "-a" repacks incrementally.  repacking every 4-5MB
+of loose objects accumulation may be a good rule of thumb.
+<4> after repack, prune removes the duplicate loose objects.
+------------
+
+Repack a small project into single pack.::
++
+------------
+$ git repack -a -d <1>
+$ git prune
+
+<1> pack all the objects reachable from the refs into one pack
+and remove unneeded other packs
+------------
+
+
+Individual Developer (Standalone)[[Individual Developer (Standalone)]]
+----------------------------------------------------------------------
+
+A standalone individual developer does not exchange patches with
+other poeple, and works alone in a single repository, using the
+following commands.
+
+  * gitlink:git-show-branch[1] to see where you are.
+
+  * gitlink:git-log[1] to see what happened.
+
+  * gitlink:git-whatchanged[1] to find out where things have
+    come from.
+
+  * gitlink:git-checkout[1] and gitlink:git-branch[1] to switch
+    branches.
+
+  * gitlink:git-add[1] and gitlink:git-update-index[1] to manage
+    the index file.
+
+  * gitlink:git-diff[1] and gitlink:git-status[1] to see what
+    you are in the middle of doing.
+
+  * gitlink:git-commit[1] to advance the current branch.
+
+  * gitlink:git-reset[1] and gitlink:git-checkout[1] (with
+    pathname parameters) to undo changes.
+
+  * gitlink:git-pull[1] with "." as the remote to merge between
+    local branches.
+
+  * gitlink:git-rebase[1] to maintain topic branches.
+
+  * gitlink:git-tag[1] to mark known point.
+
+Examples
+~~~~~~~~
+
+Extract a tarball and create a working tree and a new repository to keep track of it.::
++
+------------
+$ tar zxf frotz.tar.gz
+$ cd frotz
+$ git-init-db
+$ 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 <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 pull . 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 "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'.
+<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.
+
+  * gitlink:git-clone[1] from the upstream to prime your local
+    repository.
+
+  * gitlink:git-pull[1] and gitlink:git-fetch[1] from "origin"
+    to keep up-to-date with the upstream.
+
+  * gitlink:git-push[1] to shared repository, if you adopt CVS
+    style shared repository workflow.
+
+  * gitlink: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 whatchanged -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 prune <7>
+$ git fetch --tags <8>
+
+<1> repeat as needed.
+<2> extract patches from your branch for e-mail submission.
+<3> "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/.git frotz <1>
+satellite$ cd frotz
+satellite$ cat .git/remotes/origin <2>
+URL: mothership:frotz/.git
+Pull: master:origin
+satellite$ echo 'Push: master:satellite' >>.git/remotes/origin <3>
+satellite$ edit/compile/test/commit
+satellite$ git push origin <4>
+
+mothership$ cd frotz
+mothership$ git checkout master
+mothership$ git pull . satellite <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 creates this file by default.  It arranges "git pull"
+to fetch and store the master branch head of mothership machine
+to local "origin" branch.
+<3> arrange "git push" to push local "master" branch to
+"satellite" branch of the mothership machine.
+<4> push will stash our work away on "satellite" 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.
+
+  * gitlink:git-am[1] to apply patches e-mailed in from your
+    contributors.
+
+  * gitlink:git-pull[1] to merge from your trusted lieutenants.
+
+  * gitlink:git-format-patch[1] to prepare and send suggested
+    alternative to contributors.
+
+  * gitlink:git-revert[1] to undo botched commits.
+
+  * gitlink: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 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 master <7>
+$ git pull . topic/one topic/two && git pull . 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 master.
+<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: maint:refs/tags/ko-maint
+    Push: master
+    Push: +pu
+    Push: maint
+In the output from "git show-branch", "master" should have
+everything "ko-master" 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.
+
+  * gitlink:git-daemon[1] to allow anonymous download from
+    repository.
+
+  * gitlink: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
+~~~~~~~~
+
+Run git-daemon to serve /pub/scm from inetd.::
++
+------------
+$ grep git /etc/inet.conf
+git	stream	tcp	nowait	nobody \
+  /usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm
+------------
++
+The actual configuration line should be on one line.
+
+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

@@ -3,15 +3,39 @@
 	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.
+
+\--no-tags::
+	By default, `git-fetch` fetches tags that point at
+	objects that are downloaded from the remote repository
+	and stores them locally.  This option disables this
+	automatic tag following.
 
 -t, \--tags::
-	By default, the git core utilities will not fetch and store
-	tags under the same name as the remote repository;  ask it
-	to do so using `--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.  Note that fetching into the current branch will not
 	update the index and working directory, so use it with care.
+

Documentation/git-add.txt

@@ -31,7 +31,7 @@ DISCUSSION
 ----------
 
 The list of <file> given to the command is fed to `git-ls-files`
-command to list files that are not registerd in the index and
+command to list files that are not registered in the index and
 are not ignored/excluded by `$GIT_DIR/info/exclude` file or
 `.gitignore` file in each directory.  This means two things:
 

Documentation/git-am.txt

@@ -8,8 +8,9 @@ git-am - Apply a series of patches in a mailbox
 
 SYNOPSIS
 --------
-'git-am' [--signoff] [--dotest=<dir>] [--utf8] [--3way] <mbox>...
-'git-am' [--skip]
+[verse]
+'git-am' [--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way] <mbox>...
+'git-am' [--skip | --resolved]
 
 DESCRIPTION
 -----------
@@ -28,9 +29,13 @@ OPTIONS
 	area to store extracted patches.
 
 --utf8, --keep::
-	Pass `--utf8` and `--keep` flags to `git-mailinfo` (see
+	Pass `-u` and `-k` flags to `git-mailinfo` (see
 	gitlink:git-mailinfo[1]).
 
+--binary::
+	Pass `--allow-binary-replacement` flag to `git-apply`
+	(see gitlink:git-apply[1]).
+
 --3way::
 	When the patch does not apply cleanly, fall back on
 	3-way merge, if the patch records the identity of blobs
@@ -44,6 +49,13 @@ OPTIONS
 --interactive::
 	Run interactively, just like git-applymbox.
 
+--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.
 
 DISCUSSION
 ----------
@@ -56,12 +68,9 @@ recover from this in one of two ways:
 . skip the current one by re-running the command with '--skip'
   option.
 
-. hand resolve the conflict in the working directory, run 'git
-  diff HEAD' to extract the merge result into a patch form and
-  replacing the patch in .dotest/patch file.  After doing this,
-  run `git-reset --hard HEAD` to bring the working tree to the
-  state before half-applying the patch, then re-run the command
-  without any options.
+. 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,

Documentation/git-apply.txt

@@ -8,7 +8,10 @@ git-apply - Apply patch on a git index file and a work tree
 
 SYNOPSIS
 --------
-'git-apply' [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [-z] [<patch>...]
+[verse]
+'git-apply' [--stat] [--numstat] [--summary] [--check] [--index] [--apply]
+	  [--no-add] [--index-info] [--allow-binary-replacement] [-z] [-pNUM]
+	  [<patch>...]
 
 DESCRIPTION
 -----------
@@ -65,6 +68,10 @@ OPTIONS
 	backslash characters replaced with `\t`, `\n`, and `\\`,
 	respectively.
 
+-p<n>::
+	Remove <n> leading slashes from traditional diff paths. The
+	default is 1.
+
 --apply::
 	If you use any of the options marked ``Turns off
 	"apply"'' above, git-apply reads and outputs the

Documentation/git-archimport.txt

@@ -8,14 +8,15 @@ git-archimport - Import an Arch repository into git
 
 SYNOPSIS
 --------
-`git-archimport` [ -h ] [ -v ] [ -T ] [ -t tempdir ] 
+[verse]
+`git-archimport` [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
                <archive/branch> [ <archive/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 suppplied. If it cannot find the remote branch a merge comes from
+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). 
 
@@ -63,6 +64,26 @@ OPTIONS
 	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.
+
+-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.
 

Documentation/git-bisect.txt

@@ -8,16 +8,21 @@ git-bisect - Find the change that introduced a bug
 
 SYNOPSIS
 --------
-'git bisect' start
-'git bisect' bad <rev>
-'git bisect' good <rev>
-'git bisect' reset [<branch>]
-'git bisect' visualize
-'git bisect' replay <logfile>
-'git bisect' log
+'git bisect' <subcommand> <options> 
 
 DESCRIPTION
 -----------
+The command takes various subcommands, and different options
+depending on the subcommand:
+
+ git bisect start [<paths>...]
+ git bisect bad <rev>
+ git bisect good <rev>
+ git bisect reset [<branch>]
+ git bisect visualize
+ git bisect replay <logfile>
+ git bisect log
+
 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
@@ -26,9 +31,9 @@ object name.
 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
+$ 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
 ------------------------------------------------
 
@@ -43,7 +48,7 @@ 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
+$ git bisect good			# this one is good
 ------------------------------------------------
 
 which will now say
@@ -62,7 +67,7 @@ kernel rev in "refs/bisect/bad".
 Oh, and then after you want to reset to the original head, do a
 
 ------------------------------------------------
-git bisect reset
+$ git bisect reset
 ------------------------------------------------
 
 to get back to the master branch, instead of being in one of the bisection
@@ -72,7 +77,9 @@ not using some old bisection branch).
 
 During the bisection process, you can say
 
-	git bisect visualize
+------------
+$ git bisect visualize
+------------
 
 to see the currently remaining suspects in `gitk`.
 
@@ -80,11 +87,40 @@ 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
+------------
+$ git bisect replay that-file
+------------
 
 if you find later you made a mistake telling good/bad about a
 revision.
 
+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.
+
+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
+------------
+
 
 Author
 ------

Documentation/git-branch.txt

@@ -7,7 +7,7 @@ git-branch - Create a new branch, or remove an old one.
 
 SYNOPSIS
 --------
-'git-branch' [-d | -D] [<branchname> [start-point]]
+'git-branch' [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]]
 
 DESCRIPTION
 -----------
@@ -25,13 +25,42 @@ OPTIONS
 -D::
 	Delete a branch irrespective of its index status.
 
+-f::
+	Force a reset of <branchname> to <start-point> (or current head).
+
 <branchname>::
 	The name of the branch to create or delete.
 
-start-point::
+<start-point>::
 	Where to create the branch; defaults to HEAD. This
 	option has no meaning with -d and -D.
 
+
+Examples
+~~~~~~~~
+
+Start development off of a know 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> These two steps are the same as "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 todo <1>
+
+<1> delete todo branch even if the "master" branch does not have all
+commits from todo branch.
+------------
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>

Documentation/git-cat-file.txt

@@ -8,7 +8,7 @@ git-cat-file - Provide content or type information for repository objects
 
 SYNOPSIS
 --------
-'git-cat-file' (-t | -s | <type>) <object>
+'git-cat-file' [-t | -s | -e | <type>] <object>
 
 DESCRIPTION
 -----------
@@ -29,6 +29,10 @@ OPTIONS
 	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.
+
 <type>::
 	Typically this matches the real type of <object> but asking
 	for a type that can trivially be dereferenced from the given
@@ -39,8 +43,11 @@ OPTIONS
 
 OUTPUT
 ------
-If '-t' is specified, one of the <type>.  If '-s' is specified,
-the size of the <object> in bytes.
+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.
 
 Otherwise the raw (though uncompressed) contents of the <object> will
 be returned.

Documentation/git-check-ref-format.txt

@@ -26,13 +26,15 @@ imposes the following rules on how refs are named:
 
 . It cannot have ASCII control character (i.e. bytes whose
   values are lower than \040, or \177 `DEL`), space, tilde `~`,
-  caret `{caret}`, or colon `:` anywhere;
+  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, and also avoids ambiguities in certain refname
-expressions (see gitlink:git-rev-parse[1]).  Namely:
+refnames, pathname expansion by the shell when a refname is used
+unquoted (by mistake), and also avoids ambiguities in certain
+refname expressions (see gitlink: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

Documentation/git-checkout-index.txt

@@ -8,8 +8,9 @@ git-checkout-index - Copy files from the index to the working directory
 
 SYNOPSIS
 --------
+[verse]
 'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
-	           [--] <file>...
+		   [--stage=<number>] [--] <file>...
 
 DESCRIPTION
 -----------
@@ -40,58 +41,80 @@ OPTIONS
 	When creating files, prepend <string> (usually a directory
 	including a trailing /)
 
+--stage=<number>::
+	Instead of checking out unmerged entries, copy out the
+	files from named stage.  <number> must be between 1 and 3.
+
 --::
 	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".
+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" thing is that from scripts you are
-supposed to be able to do things like:
+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 --
+----------------
+$ 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.
 
-To update and refresh only the files already checked out:
+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.
 
-        git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
 
-Oh, and the "--" is just a good idea when you know the rest will be
-filenames. Just so that you wouldn't have a filename of "-a" causing
-problems (not possible in the above example, but get used to it in
-scripting!).
+EXAMPLES
+--------
+To update and refresh only the files already checked out::
++
+----------------
+$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+----------------
 
-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 a
-
-        git-checkout-index --prefix=git-export-dir/ -a
-
-and git-checkout-index will "export" the index into the specified
+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.
 
-NOTE The final "/" is important. The exported name is literally just
-prefixed with the specified string, so you can also do something like
+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`.
 
-    git-checkout-index --prefix=.merged- Makefile
-
-to 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>.
+Documentation by David Greaves,
+Junio C Hamano and the git-list <git@vger.kernel.org>.
+
 
 GIT
 ---

Documentation/git-checkout.txt

@@ -7,7 +7,7 @@ git-checkout - Checkout and switch to a branch.
 
 SYNOPSIS
 --------
-'git-checkout' [-f] [-b <new_branch>] [<branch>] [<paths>...]
+'git-checkout' [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]
 
 DESCRIPTION
 -----------
@@ -34,6 +34,19 @@ OPTIONS
 -b::
 	Create a new branch and start it at <branch>.
 
+-m::
+	If you have local modifications to a file that is
+	different between the current branch and the branch you
+	are switching to, the command refuses to switch
+	branches, to preserve your modifications in context.
+	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 update-index`.
+
 <new_branch>::
 	Name for the new branch.
 
@@ -42,28 +55,81 @@ OPTIONS
 	commit. Defaults to HEAD.
 
 
-EXAMPLE
--------
+EXAMPLES
+--------
 
-The following sequence checks out the `master` branch, reverts
+. 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
-$ git checkout master~2 Makefile
+$ git checkout master <1>
+$ git checkout master~2 Makefile <2>
 $ rm -f hello.c
-$ git checkout hello.c
-------------
+$ git checkout hello.c <3>
 
+<1> switch branch
+<2> take out a file out of other commit
+<3> or "git checkout -- hello.c", as in the next example.
+------------
++
 If you have an unfortunate branch that is named `hello.c`, the
 last step above 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 you would want to is done with:
++
+------------
+$ 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 update-index` as usual:
++
+------------
+$ edit frotz
+$ git update-index frotz
+------------
+
 
 Author
 ------

Documentation/git-cherry-pick.txt

@@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit.
 
 SYNOPSIS
 --------
-'git-cherry-pick' [-n] [-r] <commit>
+'git-cherry-pick' [--edit] [-n] [-r] <commit>
 
 DESCRIPTION
 -----------
@@ -20,15 +20,19 @@ OPTIONS
 <commit>::
 	Commit to cherry-pick.
 
--r::
+-e|--edit::
+	With this option, `git-cherry-pick` will let you edit the commit
+	message prior committing.
+
+-r|--replay::
 	Usually the command appends which commit was
 	cherry-picked after the original commit message when
 	making a commit.  This option, '--replay', causes it to
 	use the original commit message intact.  This is useful
 	when you are reordering the patches in your private tree
-	before publishing, and is used by 'git rebase'.
+	before publishing.
 
--n::
+-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

Documentation/git-clone-pack.txt

@@ -43,7 +43,11 @@ OPTIONS
 	The heads to update.  This is relative to $GIT_DIR
 	(e.g. "HEAD", "refs/heads/master").  When unspecified,
 	all heads are updated to match the remote repository.
-
++
+Usually all the refs from existing repository are stored
+under the same name in the new repository.  Giving explicit
+<head> arguments instead writes the object names and refs to
+the standard output, just like get-fetch-pack does.
 
 Author
 ------

Documentation/git-clone.txt

@@ -8,7 +8,9 @@ git-clone - Clones a repository.
 
 SYNOPSIS
 --------
-'git-clone' [-l [-s]] [-q] [-n] [-u <upload-pack>] <repository> [<directory>]
+[verse]
+'git-clone' [-l [-s]] [-q] [-n] [--bare] [-o <name>] [-u <upload-pack>]
+	  <repository> [<directory>]
 
 DESCRIPTION
 -----------
@@ -56,6 +58,21 @@ OPTIONS
 -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 implies `-n` option.  When
+	this option is used, neither the `origin` branch nor the
+	default	`remotes/origin` file is created.
+
+-o <name>::
+	Instead of using the branch name 'origin' to keep track
+	of the upstream repository, use <name> instead.  Note
+	that the shorthand name stored in `remotes/origin` is
+	not affected, but the local branch name to pull the
+	remote `master` branch into is.
+
 --upload-pack <upload-pack>::
 -u <upload-pack>::
 	When given, and the repository to clone from is handled
@@ -74,10 +91,47 @@ OPTIONS
 	for "host.xz:foo/.git").  Cloning into an existing directory
 	is not allowed.
 
+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
+------------
+
+
+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>.

Documentation/git-commit-tree.txt

@@ -60,7 +60,8 @@ either `.git/config` file, or using the following environment variables.
 
 (nb "<", ">" and "\n"s are stripped)
 
-In `.git/config` file, the following items are used:
+In `.git/config` file, the following items are used for GIT_AUTHOR_NAME and
+GIT_AUTHOR_EMAIL:
 
 	[user]
 		name = "Your Name"

Documentation/git-commit.txt

@@ -7,7 +7,9 @@ git-commit - Record your changes
 
 SYNOPSIS
 --------
-'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>] [-e] <file>...
+[verse]
+'git-commit' [-a] [-i] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
+	   [-e] [--author <author>] [--] <file>...
 
 DESCRIPTION
 -----------
@@ -22,8 +24,10 @@ information.
 
 OPTIONS
 -------
--a::
-	Update all paths in the index file.
+-a|--all::
+	Update all paths in the index file.  This flag notices
+	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
@@ -36,28 +40,91 @@ OPTIONS
 	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>::
 	Use the given <msg> as the commit message.
 
--s::
+-s|--signoff::
 	Add Signed-off-by line at the end of the commit message.
 
--v::
+-v|--verify::
 	Look for suspicious lines the commit introduces, and
 	abort committing if there is one.  The definition of
 	'suspicious lines' is currently the lines that has
 	trailing whitespaces, and the lines whose indentation
 	has a SP character immediately followed by a TAB
-	character.
+	character.  This is the default.
 
--e::
+-n|--no-verify::
+	The opposite of `--verify`.
+
+-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.
 
+-i|--include::
+	Instead of committing only the files specified on the
+	command line, update them in the index file and then
+	commit the whole index.  This is the traditional
+	behaviour.
+
+--::
+	Do not interpret any more arguments as options.
+
 <file>...::
-	Update specified paths in the index file before committing.
+	Commit only the files specified on the command line.
+	This format cannot be used during a merge, nor when the
+	index and the latest commit does not match on the
+	specified paths to avoid confusion.
+
+If you make a commit and then found a mistake immediately after
+that, you can recover from it with gitlink:git-reset[1].
+
+
+Discussion
+----------
+
+`git commit` without _any_ parameter commits the tree structure
+recorded by the current index file.  This is a whole-tree commit
+even the command is invoked from a subdirectory.
+
+`git commit --include paths...` is equivalent to
+
+	git update-index --remove paths...
+	git commit
+
+That is, update the specified paths to the index and then commit
+the whole tree.
+
+`git commit paths...` largely bypasses the index file and
+commits only the changes made to the specified paths.  It has
+however several safety valves to prevent confusion.
+
+. It refuses to run during a merge (i.e. when
+  `$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
+  that the traditional semantics now needs -i flag.
+
+. It refuses to run if named `paths...` are different in HEAD
+  and the index (ditto about reminding).  Added paths are OK.
+  This is because an earlier `git diff` (not `git diff HEAD`)
+  would have shown the differences since the last `git
+  update-index paths...` to the user, and an inexperienced user
+  may mistakenly think that the changes between the index and
+  the HEAD (i.e. earlier changes made before the last `git
+  update-index paths...` was done) are not being committed.
+
+. It reads HEAD commit into a temporary index file, updates the
+  specified `paths...` and makes a commit.  At the same time,
+  the real index file is also updated with the same `paths...`.
+
+`git commit --all` updates the index file with _all_ changes to
+the working tree, and makes a whole-tree commit, regardless of
+which subdirectory the command is invoked in.
 
 
 Author

Documentation/git-cvsexportcommit.txt

@@ -8,8 +8,7 @@ git-cvsexportcommit - Export a commit to a CVS checkout
 
 SYNOPSIS
 --------
-git-cvsapplycommmit.perl 
-                        [ -h ] [ -v ] [ -c ] [ -p ] [PARENTCOMMIT] COMMITID 
+'git-cvsexportcommmit' [-h] [-v] [-c] [-p] [PARENTCOMMIT] COMMITID
 
 
 DESCRIPTION
@@ -18,6 +17,7 @@ Exports a commit from GIT to a CVS checkout, making it easier
 to merge patches from a git repository into a CVS repository. 
 
 Execute it from the root of the CVS working copy. 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 
@@ -42,6 +42,26 @@ OPTIONS
 -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 .mgs <files> 
+------------
+
+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>

Documentation/git-cvsimport.txt

@@ -8,10 +8,10 @@ git-cvsimport - Import a CVS repository into git
 
 SYNOPSIS
 --------
-'git-cvsimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ]
-			[ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
-			[ -C <git_repository> ] [ -i ] [ -P <file> ] [ -k ]
-			[ -s <subst> ] [ -m ] [ -M regex ] [ <CVS_module> ]
+[verse]
+'git-cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>] [-s <subst>]
+	      [-p <options-for-cvsps>] [-C <git_repository>] [-i] [-P <file>]
+	      [-m] [-M regex] [<CVS_module>]
 
 
 DESCRIPTION
@@ -60,7 +60,7 @@ the old cvs2git tool.
 +
 If you need to pass multiple options, separate them with a comma.
 
--P:: <cvsps-output-file>
+-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.
 
@@ -89,6 +89,26 @@ If you need to pass multiple options, separate them with a comma.
 -s <subst>::
 	Substitute the character "/" in branch names with <subst>
 
+-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
+	git-link[1]::git-cvsexportcommit.
+
 OUTPUT
 ------
 If '-v' is specified, the script reports what it is doing.

Documentation/git-daemon.txt

@@ -7,8 +7,11 @@ git-daemon - A really simple server for git repositories.
 
 SYNOPSIS
 --------
+[verse]
 'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all]
-             [--timeout=n] [--init-timeout=n] [directory...]
+             [--timeout=n] [--init-timeout=n] [--strict-paths]
+             [--base-path=path] [--user-path | --user-path=path]
+	     [directory...]
 
 DESCRIPTION
 -----------
@@ -29,9 +32,22 @@ This is ideally suited for read-only updates, ie pulling from git repositories.
 
 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'.
+
 --export-all::
 	Allow pulling from all directories that look like GIT repositories
-	(have the 'objects' subdirectory and a 'HEAD' file), even if they
+	(have the 'objects' and 'refs' subdirectories), even if they
 	do not have the 'git-daemon-export-ok' file.
 
 --inetd::
@@ -54,12 +70,27 @@ OPTIONS
 	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.
 
+<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.
+
 Author
 ------
-Written by Linus Torvalds <torvalds@osdl.org> and YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
+Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki
+<yoshfuji@linux-ipv6.org> and the git-list <git@vger.kernel.org>
 
 Documentation
 --------------

Documentation/git-describe.txt

@@ -0,0 +1,79 @@
+git-describe(1)
+===============
+
+NAME
+----
+git-describe - Show the most recent tag that is reachable from a commit.
+
+
+SYNOPSIS
+--------
+'git-describe' [--all] [--tags] [--abbrev=<n>] <committish>...
+
+DESCRIPTION
+-----------
+The command finds the most recent tag that is reachable from a
+commit, and if the commit itself is pointed at by the tag, shows
+the tag.  Otherwise, it suffixes the tag name with abbreviated
+object name of the commit.
+
+
+OPTIONS
+-------
+<committish>::
+	The object name of the comittish. 
+
+--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`.
+
+--abbrev=<n>::
+	Instead of using the default 8 hexadecimal digits as the
+	abbreviated object name, use <n> digits.
+
+
+EXAMPLES
+--------
+
+With something like git.git current tree, I get:
+
+	[torvalds@g5 git]$ git-describe parent
+	v1.0.4-g2414721b
+
+i.e. the current head of my "parent" branch is based on v1.0.4,
+but since it has a few commits on top of that, it has added the
+git hash of the thing to the end: "-g" + 8-char shorthand for
+the commit `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-g975b
+
+	[torvalds@g5 git]$ git describe --all HEAD^
+	heads/lt/describe-g975b
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>, but somewhat
+butchered by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-diff-files.txt

@@ -8,7 +8,7 @@ git-diff-files - Compares files in the working tree and the index
 
 SYNOPSIS
 --------
-'git-diff-files' [-q] [<common diff options>] [<path>...]
+'git-diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
 
 DESCRIPTION
 -----------
@@ -21,6 +21,21 @@ 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.
+
 -q::
 	Remain silent even on nonexisting files
 

Documentation/git-diff-index.txt

@@ -53,7 +53,7 @@ If '--cached' is specified, it allows you to ask:
 	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 eactly
+some files in the index and are ready to commit. You want to see exactly
 *what* you are going to commit is without having to write a new tree
 object and compare it that way, and to do that, you just do
 
@@ -110,7 +110,7 @@ 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-upate-index" it to make the index be in sync.
+"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

Documentation/git-diff-tree.txt

@@ -8,7 +8,10 @@ git-diff-tree - Compares the content and mode of blobs found via two tree object
 
 SYNOPSIS
 --------
-'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty] [-t] [-r] [--root] [<common diff options>] <tree-ish> [<tree-ish>] [<path>...]
+[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
 -----------
@@ -62,7 +65,7 @@ separated with a single space are given.
 -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 supressed.  It is
+	form (with '-p').  This output can be suppressed.  It is
 	only useful with '-v' flag.
 
 -v::
@@ -78,6 +81,24 @@ separated with a single space are given.
 	git-diff-tree outputs a line with the commit ID when
 	applicable.  This flag suppressed the commit ID output.
 
+-c,--cc::
+	These flags change 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 '-m' option
+	output does.  '--cc' further compresses the output by
+	omiting 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 any other "empty diff" cases.
+
+--always::
+	Show the commit itself and the commit log message even
+	if the diff itself is empty.
+
 
 Limiting Output
 ---------------

Documentation/git-diff.txt

@@ -17,14 +17,16 @@ ent and the index file, or the index file and the working tree.
 The combination of what is compared with what is determined by
 the number of ents given to the command.
 
-`----------------`--------`-----------------------------`------------------
-Number of ents    Options  What's Compared               Underlying command
----------------------------------------------------------------------------
-0                 -        index file and working tree   git-diff-files
-1                 --cached ent and index file            git-diff-index
-1                 -        ent and working tree          git-diff-index
-2                 -        two ents                      git-diff-tree
----------------------------------------------------------------------------
+* When no <ent> is given, the working tree and the index
+  file is compared, using `git-diff-files`.
+
+* When one <ent> is given, the working tree and the named
+  tree is compared, using `git-diff-index`.  The option
+  `--cached` can be given to compare the index file and
+  the named tree.
+
+* When two <ent>s are given, these two trees are compared
+  using `git-diff-tree`.
 
 OPTIONS
 -------
@@ -38,6 +40,68 @@ OPTIONS
 	commands.
 
 
+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 since your last git-update-index.
+<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.
+------------
+
+
+Limiting the diff output::
++
+------------
+$ git diff --diff-filter=MRC <1>
+$ git diff --name-status -r <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.  --name-status disables usual patch generation
+which in turn also disables recursive behaviour, so without -r
+you would only see the directory name if there is a change in a
+file in a subdirectory.
+<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/git-fetch-pack.txt

@@ -8,7 +8,7 @@ git-fetch-pack - Receive missing objects from another repository.
 
 SYNOPSIS
 --------
-git-fetch-pack [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
+git-fetch-pack [-q] [-k] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
 
 DESCRIPTION
 -----------
@@ -29,6 +29,11 @@ OPTIONS
 	Pass '-q' flag to 'git-unpack-objects'; this makes the
 	cloning process less verbose.
 
+-k::
+	Do not invoke 'git-unpack-objects' on received data, but
+	create a single packfile out of it instead, and store it
+	in the object database.
+
 --exec=<git-upload-pack>::
 	Use this to specify the path to 'git-upload-pack' on the
 	remote side, if is not found on your $PATH.

Documentation/git-fetch.txt

@@ -18,7 +18,7 @@ the objects necessary to complete them.
 
 The ref names and their object names of fetched refs are stored
 in `.git/FETCH_HEAD`.  This information is left for a later merge
-operation done by "git resolve" or "git octopus".
+operation done by "git merge".
 
 
 OPTIONS
@@ -27,7 +27,7 @@ include::fetch-options.txt[]
 
 include::pull-fetch-param.txt[]
 
-
+include::urls.txt[]
 
 SEE ALSO
 --------

Documentation/git-format-patch.txt

@@ -8,51 +8,52 @@ git-format-patch - Prepare patches for e-mail submission.
 
 SYNOPSIS
 --------
-'git-format-patch' [-n][-o <dir>|--stdout][-k][--mbox][--diff-options] <his> [<mine>]
+[verse]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [-s] [-c]
+		 [--diff-options] <his> [<mine>]
 
 DESCRIPTION
 -----------
 Prepare each commit with its patch since <mine> head forked from
-<his> head, one file per patch, for e-mail submission.  Each
-output file is numbered sequentially from 1, and uses the first
-line of the commit message (massaged for pathname safety) as the
-filename.
+<his> head, one file per patch formatted to resemble UNIX mailbox
+format, for e-mail submission or use with gitlink:git-am[1].
 
-When -o is specified, output files are created in that
-directory; otherwise in the current working directory.
+Each output file is numbered sequentially from 1, and uses the
+first line of the commit message (massaged for pathname safety)
+as the filename.
+
+When -o is specified, output files are created in <dir>; otherwise
+they are created in the current working directory.  This option
+is ignored if --stdout is specified.
 
 When -n is specified, instead of "[PATCH] Subject", the first
 line is formatted as "[PATCH N/M] Subject", unless you have only
 one patch.
 
-When --mbox is specified, the output is formatted to resemble
-UNIX mailbox format, and can be concatenated together for
-processing with applymbox.
-
 
 OPTIONS
 -------
--o <dir>::
+-o|--output-directory <dir>::
 	Use <dir> to store the resulting files, instead of the
 	current working directory.
 
--n::
+-n|--numbered::
 	Name output in '[PATCH n/m]' format.
 
--k::
+-k|--keep-subject::
 	Do not strip/add '[PATCH]' from the first line of the
 	commit log message.
 
---author, --date::
-	Output From: and Date: headers for commits made by
-	yourself as well.  Usually these are output only for
-	commits made by people other than yourself.
+-s|--signoff::
+	Add `Signed-off-by:` line to the commit message, using
+	the committer identity of yourself.
 
---mbox::
-	Format the output files for closer to mbox format by
-	adding a phony Unix "From " line, so they can be
-	concatenated together and fed to `git-applymbox`.
-	Implies --author and --date.
+-c|--check::
+        Display suspicious lines in the patch.  The definition
+        of 'suspicious lines' is currently the lines that has
+        trailing whitespaces, and the lines whose indentation
+        has a SP character immediately followed by a TAB
+        character.
 
 --stdout::
 	This flag generates the mbox formatted output to the
@@ -73,10 +74,19 @@ git-format-patch origin::
 	pulled from origin the last time in a patch form for
 	e-mail submission.
 
+git-format-patch -M -B origin::
+	The same as the previous one, except detect and handle
+	renames and complete rewrites intelligently to produce
+	renaming patch.  A renaming patch reduces the amount of
+	text output, and generally makes it easier to review
+	it.  Note that the "patch" program does not understand
+	renaming patch well, so use it only when you know the
+	recipient uses git to apply your patch.
+
 
 See Also
 --------
-gitlink:git-am[1], gitlink:git-send-email
+gitlink:git-am[1], gitlink:git-send-email[1]
 
 
 Author

Documentation/git-fsck-objects.txt

@@ -8,7 +8,9 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
 
 SYNOPSIS
 --------
-'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache] [--standalone | --full] [--strict] [<object>*]
+[verse]
+'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache]
+		 [--standalone | --full] [--strict] [<object>*]
 
 DESCRIPTION
 -----------

Documentation/git-grep.txt

@@ -8,7 +8,7 @@ git-grep - print lines matching a pattern
 
 SYNOPSIS
 --------
-'git-grep' <option>... <pattern> <path>...
+'git-grep' [<option>...] [-e] <pattern> [--] [<path>...]
 
 DESCRIPTION
 -----------
@@ -18,16 +18,26 @@ containing a match to the given pattern.
 
 OPTIONS
 -------
+`--`::
+	Signals the end of options; the rest of the parameters
+	are <path> limiters.
+
 <option>...::
 	Either an option to pass to `grep` or `git-ls-files`.
-	Some `grep` options, such as `-C` and `-m`, that take
-	parameters are known to `git-grep`.
+
+	The following are the specific `git-ls-files` options
+	that may be given: `-o`, `--cached`, `--deleted`, `--others`,
+	`--killed`, `--ignored`, `--modified`, `--exclude=*`,
+	`--exclude-from=*`, and `--exclude-per-directory=*`.
+
+	All other options will be passed to `grep`.
 
 <pattern>::
-	The pattern to look for.
+	The pattern to look for.  The first non option is taken
+	as the pattern; if your pattern begins with a dash, use
+	`-e <pattern>`.
 
 <path>...::
-
 	Optional paths to limit the set of files to be searched;
 	passed to `git-ls-files`.
 

Documentation/git-hash-object.txt

@@ -8,7 +8,7 @@ git-hash-object - Computes object ID and optionally creates a blob from a file.
 
 SYNOPSIS
 --------
-'git-hash-object' [-t <type>] [-w] <any-file-on-the-filesystem>
+'git-hash-object' [-t <type>] [-w] [--stdin] [--] <file>...
 
 DESCRIPTION
 -----------
@@ -29,6 +29,9 @@ OPTIONS
 -w::
 	Actually write the object into the object database.
 
+--stdin::
+	Read the object from standard input instead of from a file.
+
 Author
 ------
 Written by Junio C Hamano <junkio@cox.net>

Documentation/git-http-fetch.txt

@@ -3,17 +3,23 @@ git-http-fetch(1)
 
 NAME
 ----
-git-http-fetch - Downloads a remote git repository via HTTP
+git-http-fetch - downloads a remote git repository via HTTP
 
 
 SYNOPSIS
 --------
-'git-http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] commit-id url
+'git-http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] <commit> <url>
 
 DESCRIPTION
 -----------
 Downloads a remote git repository via HTTP.
 
+OPTIONS
+-------
+commit-id::
+        Either the hash or the filename under [URL]/refs/ to
+        pull.
+
 -c::
 	Get the commit objects.
 -t::

Documentation/git-init-db.txt

@@ -8,7 +8,17 @@ git-init-db - Creates an empty git repository
 
 SYNOPSIS
 --------
-'git-init-db'
+'git-init-db' [--template=<template_directory>] [--shared]
+
+
+OPTIONS
+-------
+--template=<template_directory>::
+	Provide the directory in from which templates will be used.
+
+--shared::
+	Specify that the git repository is to be shared amongst several users.
+
 
 DESCRIPTION
 -----------
@@ -16,14 +26,38 @@ This simply creates an empty git repository - basically a `.git` directory
 and `.git/object/??/`, `.git/refs/heads` and `.git/refs/tags` directories,
 and links `.git/HEAD` symbolically to `.git/refs/heads/master`.
 
-If the 'GIT_DIR' environment variable is set then it specifies a path
+If the `$GIT_DIR` environment variable is set then it specifies a path
 to use instead of `./.git` for the base of the repository.
 
-If the object storage directory is specified via the 'GIT_OBJECT_DIRECTORY'
+If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`
 environment variable then the sha1 directories are created underneath -
 otherwise the default `$GIT_DIR/objects` directory is used.
 
-"git-init-db" won't hurt an existing repository.
+A shared repository allows users belonging to the same group to push into that
+repository. When specifying `--shared` the config variable "core.sharedRepository" 
+is set to 'true' so that directories under `$GIT_DIR` are made group writable
+(and g+sx, since the git group may be not the primary group of all users).
+
+
+Running `git-init-db` in an existing repository is safe. It will not overwrite
+things that are already there. The primary reason for rerunning `git-init-db`
+is to pick up newly added templates.
+
+
+
+EXAMPLES
+--------
+
+Start a new git repository for an existing code base::
++
+----------------
+$ cd /path/to/my/codebase
+$ git-init-db <1>
+$ git-add . <2>
+
+<1> prepare /path/to/my/codebase/.git directory
+<2> add all existing file to the index
+----------------
 
 
 Author

Documentation/git-ls-files.txt

@@ -13,7 +13,8 @@ SYNOPSIS
 		(-[c|d|o|i|s|u|k|m])\*
 		[-x <pattern>|--exclude=<pattern>]
 		[-X <file>|--exclude-from=<file>]
-		[--exclude-per-directory=<file>] [--] [<file>]\*
+		[--exclude-per-directory=<file>] 
+		[--full-name] [--] [<file>]\*
 
 DESCRIPTION
 -----------
@@ -45,6 +46,10 @@ OPTIONS
 -s|--stage::
 	Show stage files in the output
 
+--directory::
+	If a whole directory is classified as "other", show just its
+	name (with a trailing slash) and not its whole contents.
+
 -u|--unmerged::
 	Show unmerged files in the output (forces --stage)
 
@@ -73,10 +78,16 @@ OPTIONS
 	H::	cached
 	M::	unmerged
 	R::	removed/deleted
-	C::	modifed/changed
+	C::	modified/changed
 	K::	to be killed
 	?	other
 
+--full-name::
+	When run from a subdirectory, the command usually
+	outputs paths relative to the current directory.  This
+	option forces paths to be output relative to the project
+	top directory.
+
 --::
 	Do not interpret any more arguments as options.
 

Documentation/git-ls-remote.txt

@@ -17,7 +17,7 @@ Displays the references other repository has.
 
 OPTIONS
 -------
---heads --tags::
+-h|--heads, -t|--tags::
 	Limit to only refs/heads and refs/tags, respectively.
 	These options are _not_ mutually exclusive; when given
 	both, references stored in refs/heads and refs/tags are

Documentation/git-ls-tree.txt

@@ -8,12 +8,15 @@ git-ls-tree - Lists the contents of a tree object.
 
 SYNOPSIS
 --------
-'git-ls-tree' [-d] [-r] [-z] <tree-ish> [paths...]
+'git-ls-tree' [-d] [-r] [-t] [-z] [--name-only] [--name-status] <tree-ish> [paths...]
 
 DESCRIPTION
 -----------
-Lists the contents of a tree object, like what "/bin/ls -a" does
-in the current working directory.
+Lists the contents of a given tree object, like what "/bin/ls -a" does
+in the current working directory. Note that the usage is subtly different,
+though - 'paths' denote just a list of patterns to match, e.g. so specifying
+directory name (without '-r') will behave differently, and order of the
+arguments does not matter.
 
 OPTIONS
 -------
@@ -21,36 +24,48 @@ OPTIONS
 	Id of a tree-ish.
 
 -d::
-	show only the named tree entry itself, not its children
+	Show only the named tree entry itself, not its children.
 
 -r::
-	recurse into sub-trees
+	Recurse into sub-trees.
+
+-t::
+	Show tree entries even when going to recurse them. Has no effect
+	if '-r' was not passed. '-d' implies '-t'.
 
 -z::
-	\0 line termination on output
+	\0 line termination on output.
+
+--name-only::
+--name-status::
+	List only filenames (instead of the "long" output), one per line.
 
 paths::
-	When paths are given, show them.  Otherwise implicitly
-	uses the root level of the tree as the sole path argument.
+	When paths are given, show them (note that this isn't really raw
+	pathnames, but rather a list of patterns to match).  Otherwise
+	implicitly uses the root level of the tree as the sole path argument.
 
 
 Output Format
 -------------
         <mode> SP <type> SP <object> TAB <file>
 
-When `-z` option is not used, TAB, LF, and backslash characters
-in pathnames are represented as `\t`, `\n`, and `\\`,
-respectively.
+When the `-z` option is not used, TAB, LF, and backslash characters
+in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
 
 
 Author
 ------
-Written by Linus Torvalds <torvalds@osdl.org>
-Completely rewritten from scratch by Junio C Hamano <junkio@cox.net>
+Written by Petr Baudis <pasky@suse.cz>
+Completely rewritten from scratch by Junio C Hamano <junkio@cox.net>,
+another major rewrite by Linus Torvalds <torvalds@osdl.org>
 
 Documentation
 --------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+Documentation by David Greaves, Junio C Hamano and the git-list
+<git@vger.kernel.org>.
+
+This manual page is a stub. You can help the git documentation by expanding it.
 
 GIT
 ---

Documentation/git-mailinfo.txt

@@ -8,7 +8,7 @@ git-mailinfo - Extracts patch from a single e-mail message.
 
 SYNOPSIS
 --------
-'git-mailinfo' [-k] [-u] <msg> <patch>
+'git-mailinfo' [-k] [-u | --encoding=<encoding>] <msg> <patch>
 
 
 DESCRIPTION
@@ -37,10 +37,17 @@ OPTIONS
 	author email are taken from the e-mail without any
 	charset conversion, after minimally decoding MIME
 	transfer encoding.  This flag causes the resulting
-	commit to be encoded in utf-8 by transliterating them.
+	commit to be encoded in the encoding specified by
+	i18n.commitencoding configuration (defaults to utf-8) by
+	transliterating them. 
 	Note that the patch is always used as is without charset
 	conversion, even with this flag.
 
+--encoding=<encoding>::
+	Similar to -u but if the local convention is different
+	from what is specified by i18n.commitencoding, this flag
+	can be used to override it.
+
 <msg>::
 	The commit log message extracted from e-mail, usually
 	except the title line which comes from e-mail Subject.

Documentation/git-mailsplit.txt

@@ -7,7 +7,7 @@ git-mailsplit - Totally braindamaged mbox splitter program.
 
 SYNOPSIS
 --------
-'git-mailsplit' [-d<prec>] [<mbox>] <directory>
+'git-mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>...]
 
 DESCRIPTION
 -----------
@@ -23,11 +23,18 @@ OPTIONS
 <directory>::
 	Directory in which to place the individual messages.
 
+-b::
+	If any file doesn't begin with a From line, assume it is a
+	single mail message instead of signalling error.
+
 -d<prec>::
 	Instead of the default 4 digits with leading zeros,
 	different precision can be specified for the generated
 	filenames.
 
+-f<nn>::
+	Skip the first <nn> numbers, for example if -f3 is specified,
+	start the numbering with 0004.
 
 Author
 ------

Documentation/git-merge-index.txt

@@ -20,7 +20,7 @@ files are passed as arguments 5, 6 and 7.
 OPTIONS
 -------
 --::
-	Interpret all following arguments as filenames.
+	Do not interpret any more arguments as options.
 
 -a::
 	Run merge against all files in the index that need merging.

Documentation/git-merge.txt

@@ -37,6 +37,108 @@ include::merge-options.txt[]
 include::merge-strategies.txt[]
 
 
+If you tried a merge which resulted in a complex conflicts and
+would want to start over, you can recover with
+gitlink:git-reset[1].
+
+
+HOW MERGE WORKS
+---------------
+
+A merge is always between the current `HEAD` and one or more
+remote branch heads, and the index file must exactly match the
+tree of `HEAD` commit (i.e. the contents of the last commit) when
+it happens.  In other words, `git-diff --cached HEAD` must
+report no changes.
+
+[NOTE]
+This is a bit of lie.  In certain special cases, your index are
+allowed to be different from the tree of `HEAD` commit.  The most
+notable case is when your `HEAD` commit is already ahead of what
+is being merged, in which case your index can have arbitrary
+difference from your `HEAD` commit.  Otherwise, your index entries
+are allowed have differences from your `HEAD` commit that match
+the result of trivial merge (e.g. you received the same patch
+from external source to produce the same result as what you are
+merging).  For example, if a path did not exist in the common
+ancestor and your head commit but exists in the tree you are
+merging into your repository, and if you already happen to have
+that path exactly in your index, the merge does not have to
+fail.
+
+Otherwise, merge will refuse to do any harm to your repository
+(that is, it may fetch the objects from remote, and it may even
+update the local branch used to keep track of the remote branch
+with `git pull remote rbranch:lbranch`, but your working tree,
+`.git/HEAD` pointer and index file are left intact).
+
+You may have local modifications in the working tree files.  In
+other words, `git-diff` is allowed to report changes.
+However, the merge uses your working tree as the working area,
+and in order to prevent the merge operation from losing such
+changes, it makes sure that they do not interfere with the
+merge. Those complex tables in read-tree documentation define
+what it means for a path to "interfere with the merge".  And if
+your local modifications interfere with the merge, again, it
+stops before touching anything.
+
+So in the above two "failed merge" case, you do not have to
+worry about lossage of data --- you simply were not ready to do
+a merge, so no merge happened at all.  You may want to finish
+whatever you were in the middle of doing, and retry the same
+pull after you are done and ready.
+
+When things cleanly merge, these things happen:
+
+1. the results are updated both in the index file and in your
+   working tree,
+2. index file is written out as a tree,
+3. the tree gets committed, and 
+4. the `HEAD` pointer gets advanced.
+
+Because of 2., we require that the original state of the index
+file to match exactly the current `HEAD` commit; otherwise we
+will write out your local changes already registered in your
+index file along with the merge result, which is not good.
+Because 1. involves only the paths different between your
+branch and the remote branch you are pulling from during the
+merge (which is typically a fraction of the whole tree), you can
+have local modifications in your working tree as long as they do
+not overlap with what the merge updates.
+
+When there are conflicts, these things happen:
+
+1. `HEAD` stays the same.
+
+2. Cleanly merged paths are updated both in the index file and
+   in your working tree.
+
+3. For conflicting paths, the index file records up to three
+   versions; stage1 stores the version from the common ancestor,
+   stage2 from `HEAD`, and stage3 from the remote branch (you
+   can inspect the stages with `git-ls-files -u`).  The working
+   tree files have the result of "merge" program; i.e. 3-way
+   merge result with familiar conflict markers `<<< === >>>`.
+
+4. No other changes are done.  In particular, the local
+   modifications you had before you started merge will stay the
+   same and the index entries for them stay as they were,
+   i.e. matching `HEAD`.
+
+After seeing a conflict, you can do two things:
+
+ * Decide not to merge.  The only clean-up you need are to reset
+   the index file to the `HEAD` commit to reverse 2. and to clean
+   up working tree changes made by 2. and 3.; `git-reset` can
+   be used for this.
+
+ * Resolve the conflicts.  `git-diff` would report only the
+   conflicting paths because of the above 2. and 3..  Edit the
+   working tree files into a desirable shape, `git-update-index`
+   them, to make the index file contain what the merge result
+   should be, and run `git-commit` to commit the result.
+
+
 SEE ALSO
 --------
 gitlink:git-fmt-merge-msg[1], gitlink:git-pull[1]

Documentation/git-mv.txt

@@ -8,14 +8,17 @@ git-mv - Script used to move or rename a file, directory or symlink.
 
 SYNOPSIS
 --------
-'git-mv' [-f] [-n] <source> <destination>
-'git-mv' [-f] [-k] [-n] <source> ... <destination directory>
+'git-mv' <options>... <args>...
 
 DESCRIPTION
 -----------
 This script is used to move or rename a file, directory or symlink.
+
+ git-mv [-f] [-n] <source> <destination>
+ git-mv [-f] [-n] [-k] <source> ... <destination directory>
+
 In the first form, it renames <source>, which must exist and be either
-a file, symlink or directory, to <destination>, which must not exist.
+a file, symlink or directory, to <destination>.
 In the second form, the last argument has to be an existing
 directory; the given sources will be moved into this directory.
 
@@ -25,7 +28,7 @@ committed.
 OPTIONS
 -------
 -f::
-	Force renaming or moving even targets exist
+	Force renaming or moving of a file even if the target exists
 -k::
         Skip move or rename actions which would lead to an error
 	condition. An error happens when a source is neither existing nor

Documentation/git-octopus.txt

@@ -1,38 +0,0 @@
-git-octopus(1)
-==============
-
-NAME
-----
-git-octopus - Merge more than two commits.
-
-
-SYNOPSIS
---------
-'git-octopus'
-
-DESCRIPTION
------------
-After running 'git fetch', $GIT_DIR/FETCH_HEAD contains the
-following information, one line per remote ref:
-
-------------------------------------------------
-<object name>	<ref name> from <repository>
-------------------------------------------------
-
-Using this information, create and commit an Octopus merge on
-top of the current HEAD.
-
-
-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 gitlink:git[7] suite
-

Documentation/git-pack-objects.txt

@@ -8,7 +8,7 @@ git-pack-objects - Create a packed archive of objects.
 
 SYNOPSIS
 --------
-'git-pack-objects' [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list
+'git-pack-objects' [--non-empty] [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list
 
 
 DESCRIPTION
@@ -46,7 +46,7 @@ base-name::
 	output of the command.
 
 --stdout::
-	Write the pack contents (what would have been writtin to
+	Write the pack contents (what would have been written to
 	.pack file) out to the standard output.
 
 --window and --depth::
@@ -70,6 +70,10 @@ base-name::
 	that are packed and not in the local object store
 	(i.e. borrowed from an alternate).
 
+--non-empty::
+        Only create a packed archive if it would contain at
+        least one object.
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>

Documentation/git-pack-redundant.txt

@@ -16,6 +16,14 @@ This program computes which packs in your repository
 are redundant. The output is suitable for piping to
 'xargs rm' if you are in the root of the repository.
 
+git-pack-redundant accepts a list of objects on standard input. Any objects
+given will be ignored when checking which packs are required. This makes the 
+following command useful when wanting to remove packs which contain unreachable
+objects.
+
+git-fsck-objects --full --unreachable | cut -d ' ' -f3 | \
+git-pack-redundant --all | xargs rm
+
 OPTIONS
 -------
 

Documentation/git-prune-packed.txt

@@ -9,19 +9,22 @@ residing in a pack file.
 
 SYNOPSIS
 --------
-'git-prune-packed'
+'git-prune-packed' [-n]
+
 
 DESCRIPTION
 -----------
-This program search the GIT_OBJECT_DIR for all objects that currently exist in
-a pack file as well as the independent object directories.
+This program search the `$GIT_OBJECT_DIR` for all objects that currently
+exist in a pack file as well as the independent object directories.
 
 All such extra objects are removed.
 
 A pack is a collection of objects, individually compressed, with delta
 compression applied, stored in a single file, with an associated index file.
 
-Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc.
+Packs are used to reduce the load on mirror systems, backup engines,
+disk storage, etc.
+
 
 OPTIONS
 -------

Documentation/git-prune.txt

@@ -8,15 +8,16 @@ git-prune - Prunes all unreachable objects from the object database
 
 SYNOPSIS
 --------
-'git-prune' [-n]
+'git-prune' [-n] [--] [<head>...]
 
 DESCRIPTION
 -----------
 
-This runs `git-fsck-objects --unreachable` using the heads
-specified on the command line (or `$GIT_DIR/refs/heads/\*` and
-`$GIT_DIR/refs/tags/\*` if none is specified), and prunes all
-unreachable objects from the object database.  In addition, it
+This runs `git-fsck-objects --unreachable` using all the refs
+available in `$GIT_DIR/refs`, optionally with additional set of
+objects specified on the command line, and prunes all
+objects unreachable from any of these head objects from the object database.
+In addition, it
 prunes the unpacked objects that are also found in packs by
 running `git prune-packed`.
 
@@ -27,6 +28,24 @@ OPTIONS
 	Do not remove anything; just report what it would
 	remove.
 
+--::
+	Do not interpret any more arguments as options.
+
+<head>...::
+	In addition to objects
+	reachable from any of our references, keep objects
+	reachable from listed <head>s.
+
+EXAMPLE
+-------
+
+To prune objects not used by your repository nor another that
+borrows from your repository via its
+`.git/objects/info/alternates`:
+
+------------
+$ git prune $(cd ../another && $(git-rev-parse --all))
+------------
 
 Author
 ------

Documentation/git-pull.txt

@@ -29,8 +29,9 @@ include::fetch-options.txt[]
 
 include::pull-fetch-param.txt[]
 
-include::merge-strategies.txt[]
+include::urls.txt[]
 
+include::merge-strategies.txt[]
 
 EXAMPLES
 --------
@@ -104,6 +105,11 @@ merge the remote `origin` head into the current,
 local `master` branch.
 
 
+If you tried a pull which resulted in a complex conflicts and
+would want to start over, you can recover with
+gitlink:git-reset[1].
+
+
 SEE ALSO
 --------
 gitlink:git-fetch[1], gitlink:git-merge[1]

Documentation/git-push.txt

@@ -8,7 +8,7 @@ git-push - Update remote refs along with associated objects.
 
 SYNOPSIS
 --------
-'git-push' [--all] [--force] <repository> <refspec>...
+'git-push' [--all] [--tags] [--force] <repository> <refspec>...
 
 DESCRIPTION
 -----------
@@ -16,20 +16,56 @@ DESCRIPTION
 Updates remote refs using local refs, while sending objects
 necessary to complete the given refs.
 
+You can make interesting things happen to a repository
+every time you push into it, by setting up 'hooks' there.  See
+documentation for gitlink:git-receive-pack[1].
+
 
 OPTIONS
 -------
-include::pull-fetch-param.txt[]
+<repository>::
+	The "remote" repository that is destination of a push
+	operation.  See the section <<URLS,GIT URLS>> below.
+
+<refspec>::
+	The canonical format of a <refspec> parameter is
+	`+?<src>:<dst>`; that is, an optional plus `+`, followed
+	by the source ref, followed by a colon `:`, followed by
+	the destination ref.
++
+The <src> side can be an
+arbitrary "SHA1 expression" that can be used as an
+argument to `git-cat-file -t`.  E.g. `master~4` (push
+four parents before the current master head).
++
+The local ref that matches <src> is used
+to fast forward the remote ref that matches <dst>.  If
+the optional plus `+` is used, the remote ref is updated
+even if it does not result in a fast forward update.
++
+Some short-cut notations are also supported.
++
+* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+* A parameter <ref> without a colon is equivalent to
+  <ref>`:`<ref>, hence updates <ref> in the destination from <ref>
+  in the source.
 
 \--all::
-	Instead of naming each ref to push, specifies all refs
-	to be pushed.
+	Instead of naming each ref to push, specifies that all
+	refs be pushed.
+
+\--tags::
+	All refs under `$GIT_DIR/refs/tags` are pushed, in
+	addition to refspecs explicitly listed on the command
+	line.
 
 -f, \--force::
-	Usually, the command refuses to update a local ref that is
-	not an ancestor of the remote ref used to overwrite it.
-	This flag disables the check.  What this means is that the
-	local repository can lose commits; use it with care.
+	Usually, the command refuses to update a remote ref that is
+	not a descendent of the local ref used to overwrite it.
+	This flag disables the check.  This can cause the
+	remote repository to lose commits; use it with care.
+
+include::urls.txt[]
 
 Author
 ------

Documentation/git-read-tree.txt

@@ -8,31 +8,34 @@ git-read-tree - Reads tree information into the index
 
 SYNOPSIS
 --------
-'git-read-tree' (<tree-ish> | [-m [-u|-i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+'git-read-tree' (<tree-ish> | [[-m | --reset] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
 
 
 DESCRIPTION
 -----------
 Reads the tree information given by <tree-ish> into the index,
 but does not actually *update* any of the files it "caches". (see:
-git-checkout-index)
+gitlink:git-checkout-index[1])
 
 Optionally, it can merge a tree into the index, perform a
-fast-forward (i.e. 2-way) merge, or a 3-way merge, with the -m
-flag.  When used with -m, the -u flag causes it to also update
+fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m`
+flag.  When used with `-m`, the `-u` flag causes it to also update
 the files in the work tree with the result of the merge.
 
-Trivial merges are done by "git-read-tree" itself.  Only conflicting paths
-will be in unmerged state when "git-read-tree" returns.
+Trivial merges are done by `git-read-tree` itself.  Only conflicting paths
+will be in unmerged state when `git-read-tree` returns.
 
 OPTIONS
 -------
 -m::
-	Perform a merge, not just a read.
+	Perform a merge, not just a read.  The command will
+	refuse to run if your index file has unmerged entries,
+	indicating that you have not finished previous merge you
+	started.
 
 --reset::
-
-        Same as -m except that unmerged entries will be silently ignored.
+        Same as -m, except that unmerged entries are discarded
+        instead of failing.
 
 -u::
 	After a successful merge, update the files in the work
@@ -47,14 +50,13 @@ OPTIONS
 	trees that are not directly related to the current
 	working tree status into a temporary index file.
 
-
 <tree-ish#>::
 	The id of the tree object(s) to be read/merged.
 
 
 Merging
 -------
-If '-m' is specified, "git-read-tree" can perform 3 kinds of
+If `-m` is specified, `git-read-tree` can perform 3 kinds of
 merge, a single tree merge if only 1 tree is given, a
 fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
 provided.
@@ -63,23 +65,23 @@ provided.
 Single Tree Merge
 ~~~~~~~~~~~~~~~~~
 If only 1 tree is specified, git-read-tree operates as if the user did not
-specify '-m', except that if the original index has an entry for a
+specify `-m`, except that if the original index has an entry for a
 given pathname, and the contents of the path matches with the tree
 being read, the stat info from the index is used. (In other words, the
 index's stat()s take precedence over the merged tree's).
 
-That means that if you do a "git-read-tree -m <newtree>" followed by a
-"git-checkout-index -f -u -a", the "git-checkout-index" only checks out
+That means that if you do a `git-read-tree -m <newtree>` followed by a
+`git-checkout-index -f -u -a`, the `git-checkout-index` only checks out
 the stuff that really changed.
 
-This is used to avoid unnecessary false hits when "git-diff-files" is
-run after git-read-tree.
+This is used to avoid unnecessary false hits when `git-diff-files` is
+run after `git-read-tree`.
 
 
 Two Tree Merge
 ~~~~~~~~~~~~~~
 
-Typically, this is invoked as "git-read-tree -m $H $M", where $H
+Typically, this is invoked as `git-read-tree -m $H $M`, where $H
 is the head commit of the current repository, and $M is the head
 of a foreign tree, which is simply ahead of $H (i.e. we are in a
 fast forward situation).
@@ -92,7 +94,7 @@ the following:
 
      2. The user wants to fast-forward to $M.
 
-In this case, the "git-read-tree -m $H $M" command makes sure
+In this case, the `git-read-tree -m $H $M` command makes sure
 that no local change is lost as the result of this "merge".
 Here are the "carry forward" rules:
 
@@ -139,13 +141,13 @@ operating under the -u flag.
 
 When this form of git-read-tree returns successfully, you can
 see what "local changes" you made are carried forward by running
-"git-diff-index --cached $M".  Note that this does not
-necessarily match "git-diff-index --cached $H" would have
+`git-diff-index --cached $M`.  Note that this does not
+necessarily match `git-diff-index --cached $H` would have
 produced before such a two tree merge.  This is because of cases
 18 and 19 --- if you already had the changes in $M (e.g. maybe
-you picked it up via e-mail in a patch form), "git-diff-index
---cached $H" would have told you about the change before this
-merge, but it would not show in "git-diff-index --cached $M"
+you picked it up via e-mail in a patch form), `git-diff-index
+--cached $H` would have told you about the change before this
+merge, but it would not show in `git-diff-index --cached $M`
 output after two-tree merge.
 
 
@@ -154,31 +156,39 @@ output after two-tree merge.
 Each "index" entry has two bits worth of "stage" state. stage 0 is the
 normal one, and is the only one you'd see in any kind of normal use.
 
-However, when you do "git-read-tree" with three trees, the "stage"
+However, when you do `git-read-tree` with three trees, the "stage"
 starts out at 1.
 
 This means that you can do
 
-	git-read-tree -m <tree1> <tree2> <tree3>
+----------------
+$ git-read-tree -m <tree1> <tree2> <tree3>
+----------------
 
 and you will end up with an index with all of the <tree1> entries in
 "stage1", all of the <tree2> entries in "stage2" and all of the
-<tree3> entries in "stage3".
+<tree3> entries in "stage3".  When performing a merge of another
+branch into the current branch, we use the common ancestor tree
+as <tree1>, the current branch head as <tree2>, and the other
+branch head as <tree3>.
 
-Furthermore, "git-read-tree" has special-case logic that says: if you see
+Furthermore, `git-read-tree` has special-case logic that says: if you see
 a file that matches in all respects in the following states, it
 "collapses" back to "stage0":
 
    - stage 2 and 3 are the same; take one or the other (it makes no
-     difference - the same work has been done on stage 2 and 3)
+     difference - the same work has been done on our branch in
+     stage 2 and their branch in stage 3)
 
    - stage 1 and stage 2 are the same and stage 3 is different; take
-     stage 3 (some work has been done on stage 3)
+     stage 3 (our branch in stage 2 did not do anything since the
+     ancestor in stage 1 while their branch in stage 3 worked on
+     it)
 
    - stage 1 and stage 3 are the same and stage 2 is different take
-     stage 2 (some work has been done on stage 2)
+     stage 2 (we did something while they did nothing)
 
-The "git-write-tree" command refuses to write a nonsensical tree, and it
+The `git-write-tree` command refuses to write a nonsensical tree, and it
 will complain about unmerged entries if it sees a single entry that is not
 stage 0.
 
@@ -218,12 +228,10 @@ populated.  Here is an outline of how the algorithm works:
     matching "stage1" entry if it exists too.  .. all the normal
     trivial rules ..
 
-You would normally use "git-merge-index" with supplied
-"git-merge-one-file" to do this last step.  The script
-does not touch the files in the work tree, and the entire merge
-happens in the index file.  In other words, there is no need to
-worry about what is in the working directory, since it is never
-shown and never used.
+You would normally use `git-merge-index` with supplied
+`git-merge-one-file` to do this last step.  The script updates
+the files in the working tree as it merges each path and at the
+end of a successful merge.
 
 When you start a 3-way merge with an index file that is already
 populated, it is assumed that it represents the state of the
@@ -234,33 +242,54 @@ merge refuses to run if it finds an entry in the original index
 file that does not match stage 2.
 
 This is done to prevent you from losing your work-in-progress
-changes.  To illustrate, suppose you start from what has been
+changes, and mixing your random changes in an unrelated merge
+commit.  To illustrate, suppose you start from what has been
 commited last to your repository:
 
-    $ JC=`git-rev-parse --verify "HEAD^0"`
-    $ git-checkout-index -f -u -a $JC
+----------------
+$ JC=`git-rev-parse --verify "HEAD^0"`
+$ git-checkout-index -f -u -a $JC
+----------------
 
 You do random edits, without running git-update-index.  And then
 you notice that the tip of your "upstream" tree has advanced
 since you pulled from him:
 
-    $ git-fetch rsync://.... linus
-    $ LT=`cat .git/MERGE_HEAD`
+----------------
+$ git-fetch git://.... linus
+$ LT=`cat .git/FETCH_HEAD`
+----------------
 
 Your work tree is still based on your HEAD ($JC), but you have
 some edits since.  Three-way merge makes sure that you have not
 added or modified index entries since $JC, and if you haven't,
 then does the right thing.  So with the following sequence:
 
-    $ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
-    $ git-merge-index git-merge-one-file -a
-    $ echo "Merge with Linus" | \
+----------------
+$ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
+$ git-merge-index git-merge-one-file -a
+$ echo "Merge with Linus" | \
   git-commit-tree `git-write-tree` -p $JC -p $LT
+----------------
 
-what you would commit is a pure merge between $JC and LT without
+what you would commit is a pure merge between $JC and $LT without
 your work-in-progress changes, and your work tree would be
 updated to the result of the merge.
 
+However, if you have local changes in the working tree that
+would be overwritten by this merge,`git-read-tree` will refuse
+to run to prevent your changes from being lost.
+
+In other words, there is no need to worry about what exists only
+in the working tree.  When you have local changes in a part of
+the project that is not involved in the merge, your changes do
+not interfere with the merge, and are kept intact.  When they
+*do* interfere, the merge does not even start (`git-read-tree`
+complains loudly and fails without modifying anything).  In such
+a case, you can simply continue doing what you were in the
+middle of doing, and when your working tree is ready (i.e. you
+have finished your work-in-progress), attempt the merge again.
+
 
 See Also
 --------

Documentation/git-receive-pack.txt

@@ -71,6 +71,10 @@ packed and is served via a dumb transport.
 	#!/bin/sh
 	exec git-update-server-info
 
+There are other real-world examples of using update and
+post-update hooks found in the Documentation/howto directory.
+
+
 OPTIONS
 -------
 <directory>::

Documentation/git-repack.txt

@@ -9,7 +9,7 @@ objects into pack files.
 
 SYNOPSIS
 --------
-'git-repack' [-a] [-d]
+'git-repack' [-a] [-d] [-l] [-n]
 
 DESCRIPTION
 -----------
@@ -39,6 +39,13 @@ OPTIONS
 	After packing, if the newly created packs make some
 	existing packs redundant, remove the redundant packs.
 
+-l::
+        Pass the `--local` option to `git pack-objects`, see
+        gitlink:git-pack-objects[1].
+
+-n::
+        Do not update the server information with
+        `git update-server-info`.
 
 Author
 ------

Documentation/git-repo-config.txt

@@ -0,0 +1,176 @@
+git-repo-config(1)
+==================
+
+NAME
+----
+git-repo-config - Get and set options in .git/config.
+
+
+SYNOPSIS
+--------
+'git-repo-config' [type] name [value [value_regex]]
+'git-repo-config' [type] --replace-all name [value [value_regex]]
+'git-repo-config' [type] --get name [value_regex]
+'git-repo-config' [type] --get-all name [value_regex]
+'git-repo-config' [type] --unset name [value_regex]
+'git-repo-config' [type] --unset-all name [value_regex]
+
+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.
+
+If you want to set/unset an option which can occur on multiple lines, you
+should provide a POSIX regex for the value. If you want to handle the lines
+*not* matching the regex, just prepend a single exclamation mark in front
+(see EXAMPLES).
+
+The type specifier can be either '--int' or '--bool', which will make
+'git-repo-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.
+
+This command will fail if
+
+. .git/config is invalid,
+. .git/config can not be written to,
+. no section was provided,
+. the section or key is invalid,
+. you try to unset an option which does not exist, or
+. you try to unset/set an option for which multiple lines match.
+
+
+OPTIONS
+-------
+
+--replace-all::
+	Default behaviour is to replace at most one line. This replaces
+	all lines matching the key (and optionally the value_regex)
+
+--get::
+	Get the value for a given key (optionally filtered by a regex
+	matching the value).
+
+--get-all::
+	Like get, but does not fail if the number of values for the key
+	is not exactly one.
+
+--unset::
+	Remove the line matching the key from .git/config.
+
+--unset-all::
+	Remove all matching lines from .git/config.
+
+
+EXAMPLE
+-------
+
+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
+	[proxy]
+		command="ssh" for "ssh://kernel.org/"
+		command="proxy-command" for kernel.org
+		command="myprotocol-command" for "my://"
+		command=default-proxy ; for all the rest
+
+you can set the filemode to true with
+
+------------
+% git repo-config core.filemode true
+------------
+
+The hypothetic proxy command entries actually have a postfix to discern
+to what URL they apply. Here is how to change the entry for kernel.org
+to "ssh".
+
+------------
+% git repo-config proxy.command '"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 repo-config --unset diff.renames
+------------
+
+If you want to delete an entry for a multivar (like proxy.command above),
+you have to provide a regex matching the value of exactly one line.
+
+To query the value for a given key, do
+
+------------
+% git repo-config --get core.filemode
+------------
+
+or
+
+------------
+% git repo-config core.filemode
+------------
+
+or, to query a multivar:
+
+------------
+% git repo-config --get proxy.command "for kernel.org$"
+------------
+
+If you want to know all the values for a multivar, do:
+
+------------
+% git repo-config --get-all proxy.command
+------------
+
+If you like to live dangerous, you can replace *all* proxy.commands by a
+new one with
+
+------------
+% git repo-config --replace-all proxy.command 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 repo-config proxy.command ssh '! for '
+------------
+
+To actually match only values with an exclamation mark, you have to
+
+------------
+% git repo-config section.key value '[!]'
+------------
+
+
+Author
+------
+Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
+
+Documentation
+--------------
+Documentation by Johannes Schindelin.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-rerere.txt

@@ -0,0 +1,177 @@
+git-rerere(1)
+=============
+
+NAME
+----
+git-rerere - Reuse recorded resolve
+
+SYNOPSIS
+--------
+'git-rerere'
+
+
+DESCRIPTION
+-----------
+
+In a workflow that employs relatively long lived topic branches,
+the developer sometimes needs to resolve the same conflict over
+and over again until the topic branches are done (either merged
+to the "release" branch, or sent out and accepted upstream).
+
+This command helps this process by recording conflicted
+automerge results and corresponding hand-resolve results on the
+initial manual merge, and later by noticing the same automerge
+results and applying the previously recorded hand resolution.
+
+[NOTE]
+You need to create `$GIT_DIR/rr-cache` directory to enable this
+command.
+
+DISCUSSION
+----------
+
+When your topic branch modifies overlapping area that your
+master branch (or upstream) touched since your topic branch
+forked from it, you may want to test it with the latest master,
+even before your topic branch is ready to be pushed upstream:
+
+------------
+              o---*---o topic
+             /
+    o---o---o---*---o---o master
+------------
+
+For such a test, you need to merge master and topic somehow.
+One way to do it is to pull master into the topic branch:
+
+------------
+	$ git checkout topic
+	$ git pull . master
+
+              o---*---o---+ topic
+             /           /
+    o---o---o---*---o---o master
+------------
+
+The commits marked with `*` touch the same area in the same
+file; you need to resolve the conflicts when creating the commit
+marked with `+`.  Then you can test the result to make sure your
+work-in-progress still works with what is in the latest master.
+
+After this test merge, there are two ways to continue your work
+on the topic.  The easiest is to build on top of the test merge
+commit `+`, and when your work in the topic branch is finally
+ready, pull the topic branch into master, and/or ask the
+upstream to pull from you.  By that time, however, the master or
+the upstream might have been advanced since the test merge `+`,
+in which case the final commit graph would look like this:
+
+------------
+	$ git checkout topic
+	$ git pull . master
+	$ ... work on both topic and master branches
+	$ git checkout master
+	$ git pull . topic
+
+              o---*---o---+---o---o topic
+             /           /         \
+    o---o---o---*---o---o---o---o---+ master
+------------
+
+When your topic branch is long-lived, however, your topic branch
+would end up having many such "Merge from master" commits on it,
+which would unnecessarily clutter the development history.
+Readers of the Linux kernel mailing list may remember that Linus
+complained about such too frequent test merges when a subsystem
+maintainer asked to pull from a branch full of "useless merges".
+
+As an alternative, to keep the topic branch clean of test
+merges, you could blow away the test merge, and keep building on
+top of the tip before the test merge:
+
+------------
+	$ git checkout topic
+	$ git pull . master
+	$ git reset --hard HEAD^ ;# rewind the test merge
+	$ ... work on both topic and master branches
+	$ git checkout master
+	$ git pull . topic
+
+              o---*---o-------o---o topic
+             /                     \
+    o---o---o---*---o---o---o---o---+ master
+------------
+
+This would leave only one merge commit when your topic branch is
+finally ready and merged into the master branch.  This merge
+would require you to resolve the conflict, introduced by the
+commits marked with `*`.  However, often this conflict is the
+same conflict you resolved when you created the test merge you
+blew away.  `git-rerere` command helps you to resolve this final
+conflicted merge using the information from your earlier hand
+resolve.
+
+Running `git-rerere` command immediately after a conflicted
+automerge records the conflicted working tree files, with the
+usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
+them.  Later, after you are done resolving the conflicts,
+running `git-rerere` again records the resolved state of these
+files.  Suppose you did this when you created the test merge of
+master into the topic branch.
+
+Next time, running `git-rerere` after seeing a conflicted
+automerge, if the conflict is the same as the earlier one
+recorded, it is noticed and a three-way merge between the
+earlier conflicted automerge, the earlier manual resolution, and
+the current conflicted automerge is performed by the command.
+If this three-way merge resolves cleanly, the result is written
+out to your working tree file, so you would not have to manually
+resolve it.  Note that `git-rerere` leaves the index file alone,
+so you still need to do the final sanity checks with `git diff`
+(or `git diff -c`) and `git update-index` when you are
+satisfied.
+
+As a convenience measure, `git-merge` automatically invokes
+`git-rerere` when it exits with a failed automerge, which
+records it if it is a new conflict, or reuses the earlier hand
+resolve when it is not.  `git-commit` also invokes `git-rerere`
+when recording a merge result.  What this means is that you do
+not have to do anything special yourself (Note: you still have
+to create `$GIT_DIR/rr-cache` directory to enable this command).
+
+In our example, when you did the test merge, the manual
+resolution is recorded, and it will be reused when you do the
+actual merge later with updated master and topic branch, as long
+as the earlier resolution is still applicable.
+
+The information `git-rerere` records is also used when running
+`git-rebase`.  After blowing away the test merge and continuing
+development on the topic branch:
+
+------------
+              o---*---o-------o---o topic
+             /
+    o---o---o---*---o---o---o---o   master
+
+	$ git rebase master topic
+
+				  o---*---o-------o---o topic
+				 /
+    o---o---o---*---o---o---o---o   master
+------------
+
+you could run `git rebase master topic`, to keep yourself
+up-to-date even before your topic is ready to be sent upstream.
+This would result in falling back to three-way merge, and it
+would conflict the same way the test merge you resolved earlier.
+`git-rerere` is run by `git rebase` to help you resolve this
+conflict.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+GIT
+---
+Part of the gitlink:git[7] suite

Documentation/git-reset.txt

@@ -14,23 +14,163 @@ DESCRIPTION
 Sets the current head to the specified commit and optionally resets the
 index and working tree to match.
 
+This command is useful if you notice some small error in a recent
+commit (or set of commits) and want to redo that part without showing
+the undo in the history.
+
+If you want to undo a commit other than the latest on a branch,
+gitlink:git-revert[1] is your friend.
+
 OPTIONS
 -------
 --mixed::
-	Like --soft but reports what has not been updated. This is the
-	default action.
+	Resets the index but not the working tree (ie, the changed files
+	are preserved but not marked for commit) and reports what has not
+	been updated. This is the default action.
 
 --soft::
 	Does not touch the index file nor the working tree at all, but
-	requires them in a good order.
+	requires them to be in a good order. This leaves all your changed
+	files "Updated but not checked in", as gitlink:git-status[1] would
+	put it.
 
 --hard::
 	Matches the working tree and index to that of the tree being
-	switched to.
+	switched to. Any changes to tracked files in the working tree
+	since <commit-ish> are lost.
 
 <commit-ish>::
 	Commit to make the current HEAD.
 
+Examples
+~~~~~~~~
+
+Undo a commit and redo::
++
+------------
+$ git commit ...
+$ git reset --soft HEAD^ <1>
+$ edit <2>
+$ git commit -a -c ORIG_HEAD <3>
+
+<1> This is most often done when you remembered what you
+just committed is incomplete, or you misspelled your commit
+message, or both.  Leaves working tree as it was before "reset".
+<2> make corrections to working tree files.
+<3> "reset" copies the old head to .git/ORIG_HEAD; redo the
+commit by starting with its log message.  If you do not need to
+edit the message further, you can give -C option instead.
+------------
+
+Undo commits permanently::
++
+------------
+$ git commit ...
+$ git reset --hard HEAD~3 <1>
+
+<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
+and you do not want to ever see them again.  Do *not* do this if
+you have already given these commits to somebody else.
+------------
+
+Undo a commit, making it a topic branch::
++
+------------
+$ git branch topic/wip <1>
+$ git reset --hard HEAD~3 <2>
+$ git checkout topic/wip <3>
+
+<1> You have made some commits, but realize they were premature
+to be in the "master" branch.  You want to continue polishing
+them in a topic branch, so create "topic/wip" branch off of the
+current HEAD.
+<2> Rewind the master branch to get rid of those three commits.
+<3> Switch to "topic/wip" branch and keep working.
+------------
+
+Undo update-index::
++
+------------
+$ edit <1>
+$ git-update-index frotz.c filfre.c
+$ mailx <2>
+$ git reset <3>
+$ git pull git://info.example.com/ nitfol <4>
+
+<1> you are happily working on something, and find the changes
+in these files are in good order.  You do not want to see them
+when you run "git diff", because you plan to work on other files
+and changes with these files are distracting.
+<2> somebody asks you to pull, and the changes sounds worthy of merging.
+<3> however, you already dirtied the index (i.e. your index does
+not match the HEAD commit).  But you know the pull you are going
+to make does not affect frotz.c nor filfre.c, so you revert the
+index changes for these two files.  Your changes in working tree
+remain there.
+<4> then you can pull and merge, leaving frotz.c and filfre.c
+changes still in the working tree.
+------------
+
+Undo a merge or pull::
++
+------------
+$ git pull <1>
+Trying really trivial in-index merge...
+fatal: Merge requires file-level merging
+Nope.
+...
+Auto-merging nitfol
+CONFLICT (content): Merge conflict in nitfol
+Automatic merge failed/prevented; fix up by hand
+$ git reset --hard <2>
+
+<1> try to update from the upstream resulted in a lot of
+conflicts; you were not ready to spend a lot of time merging
+right now, so you decide to do that later.
+<2> "pull" has not made merge commit, so "git reset --hard"
+which is a synonym for "git reset --hard HEAD" clears the mess
+from the index file and the working tree.
+
+$ git pull . topic/branch <3>
+Updating from 41223... to 13134...
+Fast forward
+$ git reset --hard ORIG_HEAD <4>
+
+<3> merge a topic branch into the current branch, which resulted
+in a fast forward.
+<4> but you decided that the topic branch is not ready for public
+consumption yet.  "pull" or "merge" always leaves the original
+tip of the current branch in ORIG_HEAD, so resetting hard to it
+brings your index file and the working tree back to that state,
+and resets the tip of the branch to that commit.
+------------
+
+Interrupted workflow::
++
+Suppose you are interrupted by an urgent fix request while you
+are in the middle of a large change.  The files in your
+working tree are not in any shape to be committed yet, but you
+need to get to the other branch for a quick bugfix.
++
+------------
+$ git checkout feature ;# you were working in "feature" branch and
+$ work work work       ;# got interrupted
+$ git commit -a -m 'snapshot WIP' <1>
+$ git checkout master
+$ fix fix fix
+$ git commit ;# commit with real log
+$ git checkout feature
+$ git reset --soft HEAD^ ;# go back to WIP state <2>
+$ git reset <3>
+
+<1> This commit will get blown away so a throw-away log message is OK.
+<2> This removes the 'WIP' commit from the commit history, and sets
+    your working tree to the state just before you made that snapshot.
+<3> After <2>, the index file still has all the WIP changes you
+    committed in <1>.  This sets it to the last commit you were
+    basing the WIP changes on.
+------------
+
 Author
 ------
 Written by Junio C Hamano <junkio@cox.net> and Linus Torvalds <torvalds@osdl.org>
@@ -42,4 +182,3 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
 GIT
 ---
 Part of the gitlink:git[7] suite
-

Documentation/git-rev-list.txt

@@ -8,16 +8,18 @@ git-rev-list - Lists commit objects in reverse chronological order
 
 SYNOPSIS
 --------
+[verse]
 'git-rev-list' [ \--max-count=number ]
 	     [ \--max-age=timestamp ]
 	     [ \--min-age=timestamp ]
 	     [ \--sparse ]
 	     [ \--no-merges ]
+	     [ \--remove-empty ]
 	     [ \--all ]
-	[ [ \--merge-order [ \--show-breaks ] ] | [ \--topo-order ] | ]
+	     [ [ \--merge-order [ \--show-breaks ] ] | [ \--topo-order ] ]
 	     [ \--parents ]
 	     [ \--objects [ \--unpacked ] ]
-	[ \--pretty | \--header | ]
+	     [ \--pretty | \--header ]
 	     [ \--bisect ]
 	     <commit>... [ \-- <paths>... ]
 
@@ -79,6 +81,9 @@ OPTIONS
 	(still subject to count and age limitation), but apply
 	merge simplification nevertheless.
 
+--remove-empty::
+	Stop when a given path disappears from the tree.
+
 --all::
 	Pretend as if all the refs in `$GIT_DIR/refs/` are
 	listed on the command line as <commit>.
@@ -129,7 +134,7 @@ the marked commit in the list.
 +
 Commits marked with (^) are not parents of the immediately preceding commit.
 These "breaks" represent necessary discontinuities implied by trying to
-represent an arbtirary DAG in a linear form.
+represent an arbitrary DAG in a linear form.
 +
 `--show-breaks` is only valid if `--merge-order` is also specified.
 

Documentation/git-rev-parse.txt

@@ -68,10 +68,15 @@ OPTIONS
 	Show all refs found in `$GIT_DIR/refs`.
 
 --show-prefix::
-	When the command is invoked from a directory show the
+	When the command is invoked from a subdirectory, show the
 	path of the current directory relative to the top-level
 	directory.
 
+--show-cdup::
+	When the command is invoked from a subdirectory, show the
+	path of the top-level directory relative to the current
+	directory (typically a sequence of "../", or an empty string).
+
 --since=datestring, --after=datestring::
 	Parses the date string, and outputs corresponding
 	--max-age= parameter for git-rev-list command.

Documentation/git-revert.txt

@@ -7,7 +7,7 @@ git-revert - Revert an existing commit.
 
 SYNOPSIS
 --------
-'git-revert' [-n] <commit>
+'git-revert' [--edit | --no-edit] [-n] <commit>
 
 DESCRIPTION
 -----------
@@ -20,7 +20,16 @@ OPTIONS
 <commit>::
 	Commit to revert.
 
--n::
+-e|--edit::
+	With this option, `git-revert` will let you edit the commit
+	message prior committing the revert. This is the default if
+	you run the command from a terminal.
+
+--no-edit::
+	With this option, `git-revert` will not start the commit
+	message editor.
+
+-n|--no-commit::
 	Usually the command automatically creates a commit with
 	a commit log message stating which commit was reverted.
 	This flag applies the change necessary to revert the

Documentation/git-send-email.txt

@@ -24,32 +24,6 @@ OPTIONS
 -------
 The options available are:
 
---to::
-	Specify the primary recipient of the emails generated.
-	Generally, this will be the upstream maintainer of the
-	project involved.
-
---from::
-	Specify the sender of the emails.  This will default to
-	the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
-	The user will still be prompted to confirm this entry.
-
---compose::
-	Use \$EDITOR to edit an introductory message for the
-	patch series.
-
---subject::
-   	Specify the initial subject of the email thread.
-	Only necessary if --compose is also set.  If --compose
-	is not set, this will be prompted for.
-
---in-reply-to::
-	Specify the contents of the first In-Reply-To header.
-	Subsequent emails will refer to the previous email 
-	instead of this if --chain-reply-to is set (the default)
-	Only necessary if --compose is also set.  If --compose
-	is not set, this will be prompted for.
-
 --chain-reply-to, --no-chain-reply-to::
 	If this is set, each email will be sent as a reply to the previous
 	email sent.  If disabled with "--no-chain-reply-to", all emails after
@@ -58,10 +32,40 @@ The options available are:
 	entire patch series.
 	Default is --chain-reply-to
 
+--compose::
+	Use $EDITOR to edit an introductory message for the
+	patch series.
+
+--from::
+	Specify the sender of the emails.  This will default to
+	the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
+	The user will still be prompted to confirm this entry.
+
+--in-reply-to::
+	Specify the contents of the first In-Reply-To header.
+	Subsequent emails will refer to the previous email 
+	instead of this if --chain-reply-to is set (the default)
+	Only necessary if --compose is also set.  If --compose
+	is not set, this will be prompted for.
+
+--quiet::
+	Make git-send-email less verbose.  One line per email should be
+	all that is output.
+
 --smtp-server::
 	If set, specifies the outgoing SMTP server to use.  Defaults to
 	localhost.
 
+--subject::
+   	Specify the initial subject of the email thread.
+	Only necessary if --compose is also set.  If --compose
+	is not set, this will be prompted for.
+
+--to::
+	Specify the primary recipient of the emails generated.
+	Generally, this will be the upstream maintainer of the
+	project involved.
+
 
 Author
 ------

Documentation/git-show-branch.txt

@@ -7,23 +7,51 @@ git-show-branch - Show branches and their commits.
 
 SYNOPSIS
 --------
-'git-show-branch [--all] [--heads] [--tags] [--more=<n> | --list | --independent | --merge-base] [--no-name | --sha1-name] <reference>...'
+[verse]
+git-show-branch [--all] [--heads] [--tags] [--topo-order] [--current]
+	[--more=<n> | --list | --independent | --merge-base]
+	[--no-name | --sha1-name] [<rev> | <glob>]...
 
 DESCRIPTION
 -----------
-Shows the head commits from the named <reference> (or all refs under
-$GIT_DIR/refs/heads), and displays concise list of commit logs
-to show their relationship semi-visually.
+
+Shows the commit ancestry graph starting from the commits named
+with <rev>s or <globs>s (or all refs under $GIT_DIR/refs/heads
+and/or $GIT_DIR/refs/tags) semi-visually.
+
+It cannot show more than 29 branches and commits at a time.
+
+It uses `showbranch.default` multi-valued configuration items if
+no <rev> nor <glob> is given on the command line.
+
 
 OPTIONS
 -------
-<reference>::
-	Name of the reference under $GIT_DIR/refs/.
+<rev>::
+	Arbitrary extended SHA1 expression (see `git-rev-parse`)
+	that typically names a branch HEAD or a tag.
+
+<glob>::
+	A glob pattern that matches branch or tag names under
+	$GIT_DIR/refs.  For example, if you have many topic
+	branches under $GIT_DIR/refs/heads/topic, giving
+	`topic/*` would show all of them.
 
 --all --heads --tags::
 	Show all refs under $GIT_DIR/refs, $GIT_DIR/refs/heads,
 	and $GIT_DIR/refs/tags, respectively.
 
+--current::
+	With this option, the command includes the current
+	branch to the list of revs to be shown when it is not
+	given on the command line.
+
+--topo-order::
+        By default, the branches and their commits are shown in
+        reverse chronological order.  This option makes them
+        appear in topological order (i.e., descendant commits
+        are shown before their parents).
+
 --more=<n>::
 	Usually the command stops output upon showing the commit
 	that is the common ancestor of all the branches.  This
@@ -33,7 +61,7 @@ OPTIONS
 	tree.
 
 --list::
-	Synomym to `--more=-1`
+	Synonym to `--more=-1`
 
 --merge-base::
 	Instead of showing the commit list, just act like the
@@ -61,21 +89,22 @@ OUTPUT
 ------
 Given N <references>, the first N lines are the one-line
 description from their commit message.  The branch head that is
-pointed at by $GIT_DIR/HEAD is prefixed with an asterisk '*'
-character while other heads are prefixed with a '!' character.
+pointed at by $GIT_DIR/HEAD is prefixed with an asterisk `*`
+character while other heads are prefixed with a `!` character.
 
 Following these N lines, one-line log for each commit is
 displayed, indented N places.  If a commit is on the I-th
-branch, the I-th indentation character shows a '+' sign;
-otherwise it shows a space.  Each commit shows a short name that
-can be used as an exended SHA1 to name that commit.
+branch, the I-th indentation character shows a `+` sign;
+otherwise it shows a space.  Merge commits are denoted by
+a `-` sign.  Each commit shows a short name that
+can be used as an extended SHA1 to name that commit.
 
 The following example shows three branches, "master", "fixes"
 and "mhf":
 
 ------------------------------------------------
 $ git show-branch master fixes mhf
-! [master] Add 'git show-branch'.
+* [master] Add 'git show-branch'.
  ! [fixes] Introduce "reset type" flag to "git reset"
   ! [mhf] Allow "+remote:local" refspec to cause --force when fetching.
 ---
@@ -89,13 +118,33 @@ $ git show-branch master fixes mhf
   + [mhf~6] Retire git-parse-remote.
   + [mhf~7] Multi-head fetch.
   + [mhf~8] Start adding the $GIT_DIR/remotes/ support.
-+++ [master] Add 'git show-branch'.
+*++ [master] Add 'git show-branch'.
 ------------------------------------------------
 
 These three branches all forked from a common commit, [master],
 whose commit message is "Add 'git show-branch'.  "fixes" branch
 adds one commit 'Introduce "reset type"'.  "mhf" branch has many
-other commits.
+other commits.  The current branch is "master".
+
+
+EXAMPLE
+-------
+
+If you keep your primary branches immediately under
+`$GIT_DIR/refs/heads`, and topic branches in subdirectories of
+it, having the following in the configuration file may help:
+
+------------
+[showbranch]
+	default = --topo-order
+	default = heads/*
+
+------------
+
+With this,`git show-branch` without extra parameters would show
+only the primary branches.  In addition, if you happen to be on
+your topic branch, it is shown as well.
+
 
 
 Author

Documentation/git-show.txt

@@ -0,0 +1,49 @@
+git-show(1)
+===========
+
+NAME
+----
+git-show - Show one commit with difference it introduces.
+
+
+SYNOPSIS
+--------
+'git-show' <option>...
+
+DESCRIPTION
+-----------
+Shows commit log and textual diff for a single commit.  The
+command internally invokes 'git-rev-list' piped to
+'git-diff-tree', and takes command line options for both of
+these commands. It also presents the merge commit in a special
+format as produced by 'git-diff-tree --cc'.
+
+This manual page describes only the most frequently used options.
+
+
+OPTIONS
+-------
+<commitid>::
+	ID of the commit to show.
+
+--pretty=<format>::
+	Controls the output format for the commit logs.
+	<format> can be one of 'raw', 'medium', 'short', 'full',
+	and 'oneline'.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+-------------
+Documentation by David Greaves, Petr Baudis and the git-list <git@vger.kernel.org>.
+
+This manual page is a stub. You can help the git documentation by expanding it.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-svnimport.txt

@@ -10,8 +10,8 @@ git-svnimport - Import a SVN repository into git
 SYNOPSIS
 --------
 'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
-			[ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_nr_changes]
-			[ -b branch_subdir ] [ -t trunk_subdir ] [ -T tag_subdir ]
+			[ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
+			[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
 			[ -s start_chg ] [ -m ] [ -M regex ]
 			<SVN_repository_URL> [ <path> ]
 
@@ -21,7 +21,7 @@ DESCRIPTION
 Imports a SVN repository into git. It will either create a new
 repository, or incrementally import into an existing one.
 
-SVN access is done by the SVN:: Perl module.
+SVN access is done by the SVN::Perl module.
 
 git-svnimport assumes that SVN repositories are organized into one
 "trunk" directory where the main development happens, "branch/FOO"
@@ -40,17 +40,17 @@ OPTIONS
 -s <start_rev>::
         Start importing at this SVN change number. The  default is 1.
 +
-When importing incementally, you might need to edit the .git/svn2git file.
+When importing incrementally, you might need to edit the .git/svn2git file.
 
 -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.
 
--t <trunk_subdir>::
+-T <trunk_subdir>::
 	Name the SVN trunk. Default "trunk".
 
--T <tag_subdir>::
+-t <tag_subdir>::
 	Name the SVN subdirectory for tags. Default "tags".
 
 -b <branch_subdir>::
@@ -71,14 +71,11 @@ When importing incementally, you might need to edit the .git/svn2git file.
 	regex. It can be used with -m to also see the default regexes.
 	You must escape forward slashes.
 
--l <max_num_changes>::
-	Limit the number of SVN changesets we pull before quitting.
-	This option is necessary because the SVN library has serious memory
-	leaks; the recommended value for nontrivial imports is 100.
+-l <max_rev>::
+	Specify a maximum revision number to pull.
 
-	git-svnimport will still exit with a zero exit code. You can check
-	the size of the file ".git/svn2git" to determine whether to call
-	the importer again.
+	Formerly, this option controlled how many revisions to pull,
+	due to SVN memory leaks. (These have been worked around.)
 
 -v::
 	Verbosity: let 'svnimport' report what it is doing.
@@ -103,11 +100,7 @@ with a 40x error pretty quickly.
 If you're using the "-d" or "-D" option, this is the URL of the SVN
 repository itself; it usually ends in "/svn".
 
-<SVN_repository_URL>::
-	The URL of the SVN module you want to import. For local
-	repositories, use "file:///absolute/path".
-
-<path>
+<path>::
 	The path to the module you want to check out.
 
 -h::

Documentation/git-tag.txt

@@ -23,7 +23,7 @@ creates a 'tag' object, and requires the tag message.  Unless
 in the tag message.
 
 Otherwise just the SHA1 object name of the commit object is
-written (i.e. an lightweight tag).
+written (i.e. a lightweight tag).
 
 A GnuPG signed tag object will be created when `-s` or `-u
 <key-id>` is used.  When `-u <key-id>` is not used, the
@@ -32,6 +32,26 @@ GnuPG key for signing.
 
 `-d <tag>` deletes the tag.
 
+OPTIONS
+-------
+-a::
+	Make an unsigned, annotated tag object
+
+-s::
+	Make a GPG-signed tag, using the default e-mail address's key
+
+-u <key-id>::
+	Make a GPG-signed tag, using the given key
+
+-f::
+	Replace an existing tag with the given name (instead of failing)
+
+-d::
+	Delete an existing tag with the given name
+
+-m <msg>::
+	Use the given tag message (instead of prompting)
+
 
 Author
 ------

Documentation/git-update-index.txt

@@ -123,7 +123,9 @@ merging.
 
 To pretend you have a file with mode and sha1 at path, say:
 
-   $ git-update-index --cacheinfo mode sha1 path
+----------------
+$ git-update-index --cacheinfo mode sha1 path
+----------------
 
 '--info-only' is used to register files without placing them in the object
 database.  This is useful for status-only repositories.
@@ -134,11 +136,70 @@ in the database but the file isn't available locally.  '--info-only' is
 useful when the file is available, but you do not wish to update the
 object database.
 
+
+Using --index-info
+------------------
+
+`--index-info` is a more powerful mechanism that lets you feed
+multiple entry definitions from the standard input, and designed
+specifically for scripts.  It can take inputs of three formats:
+
+    . mode         SP sha1          TAB path
++
+The first format is what "git-apply --index-info"
+reports, and used to reconstruct a partial tree
+that is used for phony merge base tree when falling
+back on 3-way merge.
+
+    . mode SP type SP sha1          TAB path
++
+The second format is to stuff git-ls-tree output
+into the index file.
+
+    . mode         SP sha1 SP stage TAB path
++
+This format is to put higher order stages into the
+index file and matches git-ls-files --stage output.
+
+To place a higher stage entry to the index, the path should
+first be removed by feeding a mode=0 entry for the path, and
+then feeding necessary input lines in the third format.
+
+For example, starting with this index:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0       frotz
+------------
+
+you can feed the following input to `--index-info`:
+
+------------
+$ git update-index --index-info
+0 0000000000000000000000000000000000000000	frotz
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1	frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz
+------------
+
+The first line of the input feeds 0 as the mode to remove the
+path; the SHA1 does not matter as long as it is well formatted.
+Then the second and third line feeds stage 1 and stage 2 entries
+for that path.  After the above, we would end up with this:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1	frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz
+------------
+
+
 Examples
 --------
 To update and refresh only the files already checked out:
 
-   git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+----------------
+$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+----------------
 
 
 Configuration
@@ -146,12 +207,18 @@ Configuration
 
 The command honors `core.filemode` configuration variable.  If
 your repository is on an filesystem whose executable bits are
-unreliable, this should be set to 'false'.  This causes the
-command to ignore differences in file modes recorded in the
-index and the file mode on the filesystem if they differ only on
+unreliable, this should be set to 'false' (see gitlink:git-repo-config[1]).
+This causes the command to ignore differences in file modes recorded
+in the index and the file mode on the filesystem if they differ only on
 executable bit.   On such an unfortunate filesystem, you may
 need to use `git-update-index --chmod=`.
 
+
+See Also
+--------
+gitlink:git-repo-config[1]
+
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>

Documentation/git-update-server-info.txt

@@ -12,17 +12,17 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-A dumb server that does not do on-the-fly pack generations can
+A dumb server that does not do on-the-fly pack generations must
 have some auxiliary information files in $GIT_DIR/info and
 $GIT_OBJECT_DIRECTORY/info directories to help clients discover
-what references and packs the server has and make optimized
-pull decisions.  This command generates such auxiliary files.
+what references and packs the server has.  This command
+generates such auxiliary files.
 
 
 OPTIONS
 -------
 
---force::
+-f|--force::
 	Update the info files from scratch.
 
 

Documentation/git-verify-pack.txt

@@ -8,7 +8,7 @@ git-verify-pack - Validate packed git archive files.
 
 SYNOPSIS
 --------
-'git-verify-pack' [-v] <pack>.idx ...
+'git-verify-pack' [-v] [--] <pack>.idx ...
 
 
 DESCRIPTION
@@ -25,6 +25,8 @@ OPTIONS
 -v::
 	After verifying the pack, show list of objects contained
 	in the pack.
+--::
+	Do not interpret any more arguments as options.
 
 OUTPUT FORMAT
 -------------

Documentation/git-write-tree.txt

@@ -14,19 +14,21 @@ DESCRIPTION
 -----------
 Creates a tree object using the current index.
 
-The index must be merged.
+The index must be in a fully merged state.
 
-Conceptually, "git-write-tree" sync()s the current index contents
+Conceptually, `git-write-tree` sync()s the current index contents
 into a set of tree files.
 In order to have that match what is actually in your directory right
-now, you need to have done a "git-update-index" phase before you did the
-"git-write-tree".
+now, you need to have done a `git-update-index` phase before you did the
+`git-write-tree`.
+
 
 OPTIONS
 -------
 --missing-ok::
-	Normally "git-write-tree" ensures that the objects referenced by the
-	directory exist in the object database.  This option disables this check.
+	Normally `git-write-tree` ensures that the objects referenced by the
+	directory exist in the object database.  This option disables this
+	check.
 
 Author
 ------

Documentation/git.txt

@@ -33,34 +33,46 @@ OPTIONS
 	environment variable. If no path is given 'git' will print
 	the current setting and then exit.
 
-CORE GIT COMMANDS
------------------
-Before reading this cover to cover, you may want to take a look
-at the link:tutorial.html[tutorial] document.
 
-The <<Discussion>> section below contains much useful definition and
-clarification info - read that first.  And of the commands, I suggest
-reading gitlink:git-update-index[1] and
-gitlink:git-read-tree[1] first - I wish I had!
+NOT LEARNING CORE GIT COMMANDS
+------------------------------
 
-If you are migrating from CVS, link:cvs-migration.html[cvs migration]
-document may be helpful after you finish the tutorial.
+This manual is intended to give complete background information
+and internal workings of git, which may be too much for most
+people.  The <<Discussion>> section below contains much useful
+definition and clarification - read that first.
+
+If you are interested in using git to manage (version control)
+projects, use link:tutorial.html[The Tutorial] to get you started,
+and then link:everyday.html[Everyday GIT] as a guide to the
+minimum set of commands you need to know for day-to-day work.
+Most likely, that will get you started, and you can go a long
+way without knowing the low level details too much.
+
+The link:core-tutorial.html[Core tutorial] document covers how things
+internally work.
+
+If you are migrating from CVS, link:cvs-migration.html[cvs
+migration] document may be helpful after you finish the
+tutorial.
 
 After you get the general feel from the tutorial and this
 overview page, you may want to take a look at the
 link:howto-index.html[howto] documents.
 
 
-David Greaves <david@dgreaves.com>
-08/05/05
+CORE GIT COMMANDS
+-----------------
+
+If you are writing your own Porcelain, you need to be familiar
+with most of the low level commands --- I suggest starting from
+gitlink:git-update-index[1] and gitlink:git-read-tree[1].
 
-Updated by Junio C Hamano <junkio@cox.net> on 2005-05-05 to
-reflect recent changes.
 
 Commands Overview
 -----------------
 The git commands can helpfully be split into those that manipulate
-the repository, the index and the working fileset, those that
+the repository, the index and the files in the working tree, those that
 interrogate and compare them, and those that moves objects and
 references between repositories.
 
@@ -79,25 +91,26 @@ gitlink:git-apply[1]::
 	applies it to the working tree.
 
 gitlink:git-checkout-index[1]::
-	Copy files from the index to the working directory
+	Copy files from the index to the working tree.
 
 gitlink:git-commit-tree[1]::
-	Creates a new commit object
+	Creates a new commit object.
 
 gitlink:git-hash-object[1]::
 	Computes the object ID from a file.
 
 gitlink:git-index-pack[1]::
-	Build pack index file for an existing packed archive.
+	Build pack idx file for an existing packed archive.
 
 gitlink:git-init-db[1]::
-	Creates an empty git object database
+	Creates an empty git object database, or reinitialize an
+	existing one.
 
 gitlink:git-merge-index[1]::
-	Runs a merge for files needing merging
+	Runs a merge for files needing merging.
 
 gitlink:git-mktag[1]::
-	Creates a tag object
+	Creates a tag object.
 
 gitlink:git-pack-objects[1]::
 	Creates a packed archive of objects.
@@ -106,71 +119,80 @@ gitlink:git-prune-packed[1]::
 	Remove extra objects that are already in pack files.
 
 gitlink:git-read-tree[1]::
-	Reads tree information into the directory index
+	Reads tree information into the index.
+
+gitlink:git-repo-config[1]::
+	Get and set options in .git/config.
 
 gitlink:git-unpack-objects[1]::
 	Unpacks objects out of a packed archive.
 
 gitlink:git-update-index[1]::
-	Modifies the index or directory cache
+	Registers files in the working tree to the index.
 
 gitlink:git-write-tree[1]::
-	Creates a tree from the current index
+	Creates a tree from the index.
 
 
 Interrogation commands
 ~~~~~~~~~~~~~~~~~~~~~~
 
 gitlink:git-cat-file[1]::
-	Provide content or type information for repository objects
+	Provide content or type/size information for repository objects.
+
+gitlink:git-describe[1]::
+	Show the most recent tag that is reachable from a commit.
 
 gitlink:git-diff-index[1]::
-	Compares content and mode of blobs between the index and repository
+	Compares content and mode of blobs between the index and repository.
 
 gitlink:git-diff-files[1]::
-	Compares files in the working tree and the index
+	Compares files in the working tree and the index.
 
 gitlink:git-diff-stages[1]::
-	Compares two "merge stages" in the index file.
+	Compares two "merge stages" in the index.
 
 gitlink:git-diff-tree[1]::
-	Compares the content and mode of blobs found via two tree objects
+	Compares the content and mode of blobs found via two tree objects.
 
 gitlink:git-fsck-objects[1]::
-	Verifies the connectivity and validity of the objects in the database
+	Verifies the connectivity and validity of the objects in the database.
 
 gitlink:git-ls-files[1]::
-	Information about files in the index/working directory
+	Information about files in the index and the working tree.
 
 gitlink:git-ls-tree[1]::
-	Displays a tree object in human readable form
+	Displays a tree object in human readable form.
 
 gitlink:git-merge-base[1]::
-	Finds as good a common ancestor as possible for a merge
+	Finds as good common ancestors as possible for a merge.
 
 gitlink:git-name-rev[1]::
-	Find symbolic names for given revs
+	Find symbolic names for given revs.
+
+gitlink:git-pack-redundant[1]::
+	Find redundant pack files.
 
 gitlink:git-rev-list[1]::
-	Lists commit objects in reverse chronological order
+	Lists commit objects in reverse chronological order.
 
 gitlink:git-show-index[1]::
 	Displays contents of a pack idx file.
 
 gitlink:git-tar-tree[1]::
-	Creates a tar archive of the files in the named tree
+	Creates a tar archive of the files in the named tree object.
 
 gitlink:git-unpack-file[1]::
-	Creates a temporary file with a blob's contents
+	Creates a temporary file with a blob's contents.
 
 gitlink:git-var[1]::
-	Displays a git logical variable
+	Displays a git logical variable.
 
 gitlink:git-verify-pack[1]::
-	Validates packed git archive files
+	Validates packed git archive files.
 
-The interrogate commands may create files - and you can force them to
-touch the working file set - but in general they don't
+In general, the interrogate commands do not touch the files in
+the working tree.
 
 
 Synching repositories
@@ -178,19 +200,24 @@ Synching repositories
 
 gitlink:git-clone-pack[1]::
 	Clones a repository into the current repository (engine
-	for ssh and local transport)
+	for ssh and local transport).
 
 gitlink:git-fetch-pack[1]::
-	Updates from a remote repository.
+	Updates from a remote repository (engine for ssh and
+	local transport).
 
 gitlink:git-http-fetch[1]::
-	Downloads a remote git repository via HTTP
+	Downloads a remote git repository via HTTP by walking
+	commit chain.
 
 gitlink:git-local-fetch[1]::
-	Duplicates another git repository on a local system
+	Duplicates another git repository on a local system by
+	walking commit chain.
 
 gitlink:git-peek-remote[1]::
-	Lists references on a remote repository using upload-pack protocol.
+	Lists references on a remote repository using
+	upload-pack protocol (engine for ssh and local
+	transport).
 
 gitlink:git-receive-pack[1]::
 	Invoked by 'git-send-pack' to receive what is pushed to it.
@@ -198,14 +225,18 @@ gitlink:git-receive-pack[1]::
 gitlink:git-send-pack[1]::
 	Pushes to a remote repository, intelligently.
 
+gitlink:git-http-push[1]::
+	Push missing objects using HTTP/DAV.
+
 gitlink:git-shell[1]::
 	Restricted shell for GIT-only SSH access.
 
 gitlink:git-ssh-fetch[1]::
-	Pulls from a remote repository over ssh connection
+	Pulls from a remote repository over ssh connection by
+	walking commit chain.
 
 gitlink:git-ssh-upload[1]::
-	Helper "server-side" program used by git-ssh-fetch
+	Helper "server-side" program used by git-ssh-fetch.
 
 gitlink:git-update-server-info[1]::
 	Updates auxiliary information on a dumb server to help
@@ -220,16 +251,16 @@ Porcelain-ish Commands
 ----------------------
 
 gitlink:git-add[1]::
-	Add paths to the index file.
+	Add paths to the index.
 
 gitlink:git-am[1]::
 	Apply patches from a mailbox, but cooler.
 
 gitlink:git-applymbox[1]::
-	Apply patches from a mailbox.
+	Apply patches from a mailbox, original version by Linus.
 
 gitlink:git-bisect[1]::
-	Find the change that introduced a bug.
+	Find the change that introduced a bug by binary search.
 
 gitlink:git-branch[1]::
 	Create and Show branches.
@@ -256,7 +287,7 @@ gitlink:git-format-patch[1]::
 	Prepare patches for e-mail submission.
 
 gitlink:git-grep[1]::
-	Print lines matching a pattern
+	Print lines matching a pattern.
 
 gitlink:git-log[1]::
 	Shows commit logs.
@@ -270,9 +301,6 @@ gitlink:git-merge[1]::
 gitlink:git-mv[1]::
 	Move or rename a file, a directory, or a symlink.
 
-gitlink:git-octopus[1]::
-	Merge more than two commits.
-
 gitlink:git-pull[1]::
 	Fetch from and merge with a remote repository.
 
@@ -280,11 +308,14 @@ gitlink:git-push[1]::
 	Update remote refs along with associated objects.
 
 gitlink:git-rebase[1]::
-	Rebase local commits to new upstream head.
+	Rebase local commits to the updated upstream head.
 
 gitlink:git-repack[1]::
 	Pack unpacked objects in a repository.
 
+gitlink:git-rerere[1]::
+	Reuse recorded resolution of conflicted merges.
+
 gitlink:git-reset[1]::
 	Reset current HEAD to the specified state.
 
@@ -321,19 +352,22 @@ gitlink:git-archimport[1]::
 	Import an arch repository into git.
 
 gitlink:git-convert-objects[1]::
-	Converts old-style git repository
+	Converts old-style git repository.
 
 gitlink:git-cvsimport[1]::
 	Salvage your data out of another SCM people love to hate.
 
+gitlink:git-cvsexportcommit[1]::
+	Export a single commit to a CVS checkout.
+
 gitlink:git-lost-found[1]::
 	Recover lost refs that luckily have not yet been pruned.
 
 gitlink:git-merge-one-file[1]::
-	The standard helper program to use with "git-merge-index"
+	The standard helper program to use with `git-merge-index`.
 
 gitlink:git-prune[1]::
-	Prunes all unreachable objects from the object database
+	Prunes all unreachable objects from the object database.
 
 gitlink:git-relink[1]::
 	Hardlink common objects in local repositories.
@@ -345,10 +379,10 @@ gitlink:git-sh-setup[1]::
 	Common git shell script setup code.
 
 gitlink:git-symbolic-ref[1]::
-	Read and modify symbolic refs
+	Read and modify symbolic refs.
 
 gitlink:git-tag[1]::
-	An example script to create a tag object signed with GPG
+	An example script to create a tag object signed with GPG.
 
 gitlink:git-update-ref[1]::
 	Update the object name stored in a ref safely.
@@ -372,16 +406,19 @@ gitlink:git-get-tar-commit-id[1]::
 	Extract commit ID from an archive created using git-tar-tree.
 
 gitlink:git-mailinfo[1]::
-	Extracts patch from a single e-mail message.
+	Extracts patch and authorship information from a single
+	e-mail message, optionally transliterating the commit
+	message into utf-8.
 
 gitlink:git-mailsplit[1]::
-	git-mailsplit.
+	A stupid program to split UNIX mbox format mailbox into
+	individual pieces of e-mail.
 
 gitlink:git-patch-id[1]::
 	Compute unique ID for a patch.
 
 gitlink:git-parse-remote[1]::
-	Routines to help parsing $GIT_DIR/remotes/
+	Routines to help parsing `$GIT_DIR/remotes/` files.
 
 gitlink:git-request-pull[1]::
 	git-request-pull.
@@ -392,7 +429,7 @@ gitlink:git-rev-parse[1]::
 gitlink:git-send-email[1]::
 	Send patch e-mails out of "format-patch --mbox" output.
 
-gitlink:git-symbolic-refs[1]::
+gitlink:git-symbolic-ref[1]::
 	Read and modify symbolic refs.
 
 gitlink:git-stripspace[1]::
@@ -403,22 +440,20 @@ Commands not yet documented
 ---------------------------
 
 gitlink:gitk[1]::
-	gitk.
+	The gitk repository browser.
 
 
 Configuration Mechanism
 -----------------------
 
-Starting from 0.99.9 (actually mid 0.99.8.GIT), .git/config file
+Starting from 0.99.9 (actually mid 0.99.8.GIT), `.git/config` file
 is used to hold per-repository configuration options.  It is a
 simple text file modelled after `.ini` format familiar to some
 people.  Here is an example:
 
 ------------
 #
-# This is the config file, and
-# a '#' or ';' character indicates
-# a comment
+# A '#' or ';' character indicates a comment.
 #
 
 ; core variables
@@ -440,30 +475,30 @@ their operation accordingly.
 Identifier Terminology
 ----------------------
 <object>::
-	Indicates the sha1 identifier for any type of object
+	Indicates the object name for any type of object.
 
 <blob>::
-	Indicates a blob object sha1 identifier
+	Indicates a blob object name.
 
 <tree>::
-	Indicates a tree object sha1 identifier
+	Indicates a tree object name.
 
 <commit>::
-	Indicates a commit object sha1 identifier
+	Indicates a commit object name.
 
 <tree-ish>::
-	Indicates a tree, commit or tag object sha1 identifier.  A
+	Indicates a tree, commit or tag object name.  A
 	command that takes a <tree-ish> argument ultimately wants to
 	operate on a <tree> object but automatically dereferences
 	<commit> and <tag> objects that point at a <tree>.
 
 <type>::
 	Indicates that an object type is required.
-	Currently one of: blob/tree/commit/tag
+	Currently one of: `blob`, `tree`, `commit`, or `tag`.
 
 <file>::
-	Indicates a filename - always relative to the root of
-	the tree structure GIT_INDEX_FILE describes.
+	Indicates a filename - almost always relative to the
+	root of the tree structure `GIT_INDEX_FILE` describes.
 
 Symbolic Identifiers
 --------------------
@@ -471,17 +506,20 @@ Any git command accepting any <object> can also use the following
 symbolic notation:
 
 HEAD::
-	indicates the head of the repository (ie the contents of
-	`$GIT_DIR/HEAD`)
+	indicates the head of the current branch (i.e. the
+	contents of `$GIT_DIR/HEAD`).
+
 <tag>::
-	a valid tag 'name'+
-	(ie the contents of `$GIT_DIR/refs/tags/<tag>`)
+	a valid tag 'name'
+	(i.e. the contents of `$GIT_DIR/refs/tags/<tag>`).
+
 <head>::
-	a valid head 'name'+
-	(ie the contents of `$GIT_DIR/refs/heads/<head>`)
+	a valid head 'name'
+	(i.e. the contents of `$GIT_DIR/refs/heads/<head>`).
+
 <snap>::
-	a valid snapshot 'name'+
-	(ie the contents of `$GIT_DIR/refs/snap/<snap>`)
+	a valid snapshot 'name'
+	(i.e. the contents of `$GIT_DIR/refs/snap/<snap>`).
 
 
 File/Directory Structure
@@ -490,7 +528,7 @@ File/Directory Structure
 Please see link:repository-layout.html[repository layout] document.
 
 Higher level SCMs may provide and manage additional information in the
-GIT_DIR.
+`$GIT_DIR`.
 
 
 Terminology
@@ -506,7 +544,7 @@ The git Repository
 ~~~~~~~~~~~~~~~~~~
 These environment variables apply to 'all' core git commands. Nb: it
 is worth noting that they may be used/overridden by SCMS sitting above
-git so take care if using Cogito etc
+git so take care if using Cogito etc.
 
 'GIT_INDEX_FILE'::
 	This environment allows the specification of an alternate
@@ -527,9 +565,9 @@ git so take care if using Cogito etc
 	written to these directories.
 
 'GIT_DIR'::
-	If the 'GIT_DIR' environment variable is set then it specifies
-	a path to use instead of `./.git` for the base of the
-	repository.
+	If the 'GIT_DIR' environment variable is set then it
+	specifies a path to use instead of the default `.git`
+	for the base of the repository.
 
 git Commits
 ~~~~~~~~~~~
@@ -551,18 +589,20 @@ git Diffs
 
 Discussion[[Discussion]]
 ------------------------
-include::../README[]
+include::README[]
 
 Authors
 -------
-	git's founding father is Linus Torvalds <torvalds@osdl.org>.
-	The current git nurse is Junio C. Hamano <junkio@cox.net>.
-	The git potty was written by Andres Ericsson <ae@op5.se>.
-	General upbringing is handled by the git-list <git@vger.kernel.org>.
+* git's founding father is Linus Torvalds <torvalds@osdl.org>.
+* The current git nurse is Junio C Hamano <junkio@cox.net>.
+* The git potty was written by Andres Ericsson <ae@op5.se>.
+* General upbringing is handled by the git-list <git@vger.kernel.org>.
 
 Documentation
 --------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+The documentation for git suite was started by David Greaves
+<david@dgreaves.com>, and later enhanced greatly by the
+contributors on the git-list <git@vger.kernel.org>.
 
 GIT
 ---

Documentation/glossary.txt

@@ -19,8 +19,8 @@ hash::
 	In git's context, synonym to object name.
 
 object database::
-	Stores a set of "objects", and an individial object is identified
-	by its object name. The object usually live in $GIT_DIR/objects/.
+	Stores a set of "objects", and an individual object is identified
+	by its object name. The objects usually live in `$GIT_DIR/objects/`.
 
 blob object::
 	Untyped object, e.g. the contents of a file.
@@ -109,15 +109,26 @@ head::
 branch::
 	A non-cyclical graph of revisions, i.e. the complete history of
 	a particular revision, which is called the branch head. The
-	branch heads are stored in $GIT_DIR/refs/heads/.
+	branch heads are stored in `$GIT_DIR/refs/heads/`.
+
+master::
+	The default branch. Whenever you create a git repository, a branch
+	named "master" is created, and becomes the active branch. In most
+	cases, this contains the local development.
+
+origin::
+	The default upstream branch. Most projects have one upstream
+	project which they track, and by default 'origin' is used for
+	that purpose.  New updates from upstream will be fetched into
+	this branch; you should never commit to it yourself.
 
 ref::
 	A 40-byte hex representation of a SHA1 pointing to a particular
-	object. These may be stored in $GIT_DIR/refs/.
+	object. These may be stored in `$GIT_DIR/refs/`.
 
 head ref::
 	A ref pointing to a head. Often, this is abbreviated to "head".
-	Head refs are stored in $GIT_DIR/refs/heads/.
+	Head refs are stored in `$GIT_DIR/refs/heads/`.
 
 tree-ish::
 	A ref pointing to either a commit object, a tree object, or a
@@ -125,7 +136,7 @@ tree-ish::
 
 ent::
 	Favorite synonym to "tree-ish" by some total geeks. See
-	http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth
+	`http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
 	explanation.
 
 tag object::
@@ -137,7 +148,7 @@ tag object::
 tag::
 	A ref pointing to a tag or commit object. In contrast to a head,
 	a tag is not changed by a commit. Tags (not tag objects) are
-	stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with
+	stored in `$GIT_DIR/refs/tags/`. A git tag has nothing to do with
 	a Lisp tag (which is called object type in git's context).
 	A tag is most typically used to mark a particular point in the
 	commit ancestry chain.

Documentation/hooks.txt

@@ -111,6 +111,10 @@ Another use suggested on the mailing list is to use this hook to
 implement access control which is finer grained than the one
 based on filesystem group.
 
+The standard output of this hook is sent to /dev/null; if you
+want to report something to the git-send-pack on the other end,
+you can redirect your output to your stderr.
+
 post-update
 -----------
 
@@ -125,3 +129,7 @@ the outcome of `git-receive-pack`.
 The default post-update hook, when enabled, runs
 `git-update-server-info` to keep the information used by dumb
 transport up-to-date.
+
+The standard output of this hook is sent to /dev/null; if you
+want to report something to the git-send-pack on the other end,
+you can redirect your output to your stderr.

Documentation/howto/isolate-bugs-with-bisect.txt

@@ -24,7 +24,7 @@ Then do
 	git bisect bad master		<- mark "master" as the bad state
 	git bisect good ORIG_HEAD	<- mark ORIG_HEAD as good (or
 					   whatever other known-good 
-					   thing you booted laste)
+					   thing you booted last)
 
 and at this point "git bisect" will churn for a while, and tell you what 
 the mid-point between those two commits are, and check that state out as 

Documentation/howto/rebase-from-internal-branch.txt

@@ -40,10 +40,7 @@ So I started from master, made a bunch of edits, and committed:
     $ git checkout master
     $ cd Documentation; ed git.txt ...
     $ cd ..; git add Documentation/*.txt
-    $ git commit -s -v
-
-NOTE.  The -v flag to commit is a handy way to make sure that
-your additions are not introducing bogusly formatted lines.
+    $ git commit -s
 
 After the commit, the ancestry graph would look like this:
 
@@ -98,7 +95,7 @@ to do cherrypicking using only the core GIT tools.
 Let's go back to the earlier picture, with different labels.
 
 You, as an individual developer, cloned upstream repository and
-amde a couple of commits on top of it.
+made a couple of commits on top of it.
 
                               *your "master" head
    upstream --> #1 --> #2 --> #3

Documentation/howto/rebuild-from-update-hook.txt

@@ -10,7 +10,7 @@ The pages under http://www.kernel.org/pub/software/scm/git/docs/
 are built from Documentation/ directory of the git.git project
 and needed to be kept up-to-date.  The www.kernel.org/ servers
 are mirrored and I was told that the origin of the mirror is on
-the machine master.kernel.org, on which I was given an account
+the machine $some.kernel.org, on which I was given an account
 when I took over git maintainership from Linus.
 
 The directories relevant to this how-to are these two:
@@ -63,7 +63,7 @@ like this:
     EOF
     $ chmod +x /pub/scm/git/git.git/hooks/post-update
 
-There are three things worth mentioning:
+There are four things worth mentioning:
 
  - The update-hook is run after the repository accepts a "git
    push", under my user privilege.  It is given the full names
@@ -77,6 +77,10 @@ There are three things worth mentioning:
    pull" it does into $HOME/doc-git/docgen/ repository would not
    work correctly.
 
+ - The stdout of update hook script is not connected to git
+   push; I run the heavy part of the command inside "at", to
+   receive the execution report via e-mail.
+
  - This is still crude and does not protect against simultaneous
    make invocations stomping on each other.  I would need to add
    some locking mechanism for this.

Documentation/howto/revert-branch-rebase.txt

@@ -32,16 +32,16 @@ merge introduced 5 commits or so:
 
 ------------------------------------------------
 $ git show-branch --more=4 master master^2 | head
-! [master] Merge refs/heads/portable from http://www.cs.berkeley....
+* [master] Merge refs/heads/portable from http://www.cs.berkeley....
  ! [master^2] Replace C99 array initializers with code.
 --
-+  [master] Merge refs/heads/portable from http://www.cs.berkeley....
-++ [master^2] Replace C99 array initializers with code.
-++ [master^2~1] Replace unsetenv() and setenv() with older putenv().
-++ [master^2~2] Include sys/time.h in daemon.c.
-++ [master^2~3] Fix ?: statements.
-++ [master^2~4] Replace zero-length array decls with [].
-+  [master~1] tutorial note about git branch
+-  [master] Merge refs/heads/portable from http://www.cs.berkeley....
+*+ [master^2] Replace C99 array initializers with code.
+*+ [master^2~1] Replace unsetenv() and setenv() with older putenv().
+*+ [master^2~2] Include sys/time.h in daemon.c.
+*+ [master^2~3] Fix ?: statements.
+*+ [master^2~4] Replace zero-length array decls with [].
+*  [master~1] tutorial note about git branch
 ------------------------------------------------
 
 The '--more=4' above means "after we reach the merge base of refs,
@@ -193,8 +193,8 @@ $ git show-branch --more=1 master pu rc
  +  [pu~4] Document "git cherry-pick" and "git revert"
  +  [pu~5] Remove git-apply-patch-script.
  +  [pu~6] Redo "revert" using three-way merge machinery.
-  + [rc] Merge refs/heads/master from .
-+++ [master] Revert "Replace zero-length array decls with []."
-  + [rc~1] Merge refs/heads/master from .
-+++ [master~1] Merge refs/heads/portable from http://www.cs.berkeley....
+  - [rc] Merge refs/heads/master from .
+++* [master] Revert "Replace zero-length array decls with []."
+  - [rc~1] Merge refs/heads/master from .
+... [master~1] Merge refs/heads/portable from http://www.cs.berkeley....
 ------------------------------------------------

Documentation/howto/separating-topic-branches.txt

@@ -0,0 +1,91 @@
+From: Junio C Hamano <junkio@cox.net>
+Subject: Separating topic branches
+Abstract: In this article, JC describes how to separate topic branches.
+
+This text was originally a footnote to a discussion about the
+behaviour of the git diff commands.
+
+Often I find myself doing that [running diff against something other
+than HEAD] while rewriting messy development history.  For example, I
+start doing some work without knowing exactly where it leads, and end
+up with a history like this:
+
+            "master"
+        o---o
+             \                    "topic" 
+              o---o---o---o---o---o
+
+At this point, "topic" contains something I know I want, but it
+contains two concepts that turned out to be completely independent.
+And often, one topic component is larger than the other.  It may
+contain more than two topics.
+
+In order to rewrite this mess to be more manageable, I would first do
+"diff master..topic", to extract the changes into a single patch, start
+picking pieces from it to get logically self-contained units, and
+start building on top of "master":
+
+        $ git diff master..topic >P.diff
+        $ git checkout -b topicA master
+        ... pick and apply pieces from P.diff to build
+        ... commits on topicA branch.
+                      
+              o---o---o
+             /        "topicA"
+        o---o"master"
+             \                    "topic" 
+              o---o---o---o---o---o
+
+Before doing each commit on "topicA" HEAD, I run "diff HEAD"
+before update-index the affected paths, or "diff --cached HEAD"
+after.  Also I would run "diff --cached master" to make sure
+that the changes are only the ones related to "topicA".  Usually
+I do this for smaller topics first.
+
+After that, I'd do the remainder of the original "topic", but
+for that, I do not start from the patchfile I extracted by
+comparing "master" and "topic" I used initially.  Still on
+"topicA", I extract "diff topic", and use it to rebuild the
+other topic:
+
+        $ git diff -R topic >P.diff ;# --cached also would work fine
+        $ git checkout -b topicB master
+        ... pick and apply pieces from P.diff to build
+        ... commits on topicB branch.
+
+                                "topicB"
+               o---o---o---o---o
+              /
+             /o---o---o
+            |/        "topicA"
+        o---o"master"
+             \                    "topic" 
+              o---o---o---o---o---o
+
+After I am done, I'd try a pretend-merge between "topicA" and
+"topicB" in order to make sure I have not missed anything:
+
+        $ git pull . topicA ;# merge it into current "topicB"
+        $ git diff topic
+                                "topicB"
+               o---o---o---o---o---* (pretend merge)
+              /                   /
+             /o---o---o----------'
+            |/        "topicA"
+        o---o"master"
+             \                    "topic" 
+              o---o---o---o---o---o
+
+The last diff better not to show anything other than cleanups
+for crufts.  Then I can finally clean things up:
+
+        $ git branch -D topic
+        $ git reset --hard HEAD^ ;# nuke pretend merge
+
+                                "topicB"
+               o---o---o---o---o
+              / 
+             /o---o---o
+            |/        "topicA"
+        o---o"master"
+

Documentation/howto/update-hook-example.txt

@@ -0,0 +1,172 @@
+From: Junio C Hamano <junkio@cox.net> and Carl Baldwin <cnb@fc.hp.com>
+Subject: control access to branches.
+Date: Thu, 17 Nov 2005 23:55:32 -0800
+Message-ID: <7vfypumlu3.fsf@assigned-by-dhcp.cox.net>
+Abstract: An example hooks/update script is presented to
+ implement repository maintenance policies, such as who can push
+ into which branch and who can make a tag.
+
+When your developer runs git-push into the repository,
+git-receive-pack is run (either locally or over ssh) as that
+developer, so is hooks/update script.  Quoting from the relevant
+section of the documentation:
+
+    Before each ref is updated, if $GIT_DIR/hooks/update file exists
+    and executable, it is called with three parameters:
+
+           $GIT_DIR/hooks/update refname sha1-old sha1-new
+
+    The refname parameter is relative to $GIT_DIR; e.g. for the
+    master head this is "refs/heads/master".  Two sha1 are the
+    object names for the refname before and after the update.  Note
+    that the hook is called before the refname is updated, so either
+    sha1-old is 0{40} (meaning there is no such ref yet), or it
+    should match what is recorded in refname.
+
+So if your policy is (1) always require fast-forward push
+(i.e. never allow "git-push repo +branch:branch"), (2) you
+have a list of users allowed to update each branch, and (3) you
+do not let tags to be overwritten, then you can use something
+like this as your hooks/update script.
+
+[jc: editorial note.  This is a much improved version by Carl
+since I posted the original outline]
+
+-- >8 -- beginning of script -- >8 --
+
+#!/bin/bash
+
+umask 002
+
+# If you are having trouble with this access control hook script
+# you can try setting this to true.  It will tell you exactly
+# why a user is being allowed/denied access.
+
+verbose=false
+
+# Default shell globbing messes things up downstream
+GLOBIGNORE=*
+
+function grant {
+  $verbose && echo >&2 "-Grant-		$1"
+  echo grant
+  exit 0
+}
+
+function deny {
+  $verbose && echo >&2 "-Deny-		$1"
+  echo deny
+  exit 1
+}
+
+function info {
+  $verbose && echo >&2 "-Info-		$1"
+}
+
+# Implement generic branch and tag policies.
+# - Tags should not be updated once created.
+# - Branches should only be fast-forwarded.
+case "$1" in
+  refs/tags/*)
+    [ -f "$GIT_DIR/$1" ] &&
+    deny >/dev/null "You can't overwrite an existing tag"
+    ;;
+  refs/heads/*)
+    # No rebasing or rewinding
+    if expr "$2" : '0*$' >/dev/null; then
+      info "The branch '$1' is new..."
+    else
+      # updating -- make sure it is a fast forward
+      mb=$(git-merge-base "$2" "$3")
+      case "$mb,$2" in
+        "$2,$mb") info "Update is fast-forward" ;;
+        *)        deny >/dev/null  "This is not a fast-forward update." ;;
+      esac
+    fi
+    ;;
+  *)
+    deny >/dev/null \
+    "Branch is not under refs/heads or refs/tags.  What are you trying to do?"
+    ;;
+esac
+
+# Implement per-branch controls based on username
+allowed_users_file=$GIT_DIR/info/allowed-users
+username=$(id -u -n)
+info "The user is: '$username'"
+
+if [ -f "$allowed_users_file" ]; then
+  rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' |
+    while read head_pattern user_patterns; do
+      matchlen=$(expr "$1" : "$head_pattern")
+      if [ "$matchlen" == "${#1}" ]; then
+        info "Found matching head pattern: '$head_pattern'"
+        for user_pattern in $user_patterns; do
+          info "Checking user: '$username' against pattern: '$user_pattern'"
+          matchlen=$(expr "$username" : "$user_pattern")
+          if [ "$matchlen" == "${#username}" ]; then
+            grant "Allowing user: '$username' with pattern: '$user_pattern'"
+          fi
+        done
+        deny "The user is not in the access list for this branch"
+      fi
+    done
+  )
+  case "$rc" in
+    grant) grant >/dev/null "Granting access based on $allowed_users_file" ;;
+    deny)  deny  >/dev/null "Denying  access based on $allowed_users_file" ;;
+    *) ;;
+  esac
+fi
+
+allowed_groups_file=$GIT_DIR/info/allowed-groups
+groups=$(id -G -n)
+info "The user belongs to the following groups:"
+info "'$groups'"
+
+if [ -f "$allowed_groups_file" ]; then
+  rc=$(cat $allowed_groups_file | grep -v '^#' | grep -v '^$' |
+    while read head_pattern group_patterns; do
+      matchlen=$(expr "$1" : "$head_pattern")
+      if [ "$matchlen" == "${#1}" ]; then
+        info "Found matching head pattern: '$head_pattern'"
+        for group_pattern in $group_patterns; do
+          for groupname in $groups; do
+            info "Checking group: '$groupname' against pattern: '$group_pattern'"
+            matchlen=$(expr "$groupname" : "$group_pattern")
+            if [ "$matchlen" == "${#groupname}" ]; then
+              grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
+            fi
+          done
+        done
+        deny "None of the user's groups are in the access list for this branch"
+      fi
+    done
+  )
+  case "$rc" in
+    grant) grant >/dev/null "Granting access based on $allowed_groups_file" ;;
+    deny)  deny  >/dev/null "Denying  access based on $allowed_groups_file" ;;
+    *) ;;
+  esac
+fi
+
+deny >/dev/null "There are no more rules to check.  Denying access"
+
+-- >8 -- end of script -- >8 --
+
+This uses two files, $GIT_DIR/info/allowed-users and
+allowed-groups, to describe which heads can be pushed into by
+whom.  The format of each file would look like this:
+
+	refs/heads/master	junio
+        refs/heads/cogito$	pasky
+	refs/heads/bw/		linus
+        refs/heads/tmp/		*
+        refs/tags/v[0-9]*	junio
+
+With this, Linus can push or create "bw/penguin" or "bw/zebra"
+or "bw/panda" branches, Pasky can do only "cogito", and JC can
+do master branch and make versioned tags.  And anybody can do
+tmp/blah branches.
+
+------------

Documentation/howto/using-topic-branches.txt

@@ -9,7 +9,7 @@ GIT as a Linux subsystem maintainer.
 
 -Tony
 
-Last updated w.r.t. GIT 0.99.9f
+Last updated w.r.t. GIT 1.1
 
 Linux subsystem maintenance using GIT
 -------------------------------------
@@ -31,7 +31,7 @@ test tree and then pull to the release tree as that would leave trivial
 patches blocked in the test tree waiting for complex changes to accumulate
 enough test time to graduate.
 
-Back in the BitKeeper days I achieved this my creating small forests of
+Back in the BitKeeper days I achieved this by creating small forests of
 temporary trees, one tree for each logical grouping of patches, and then
 pulling changes from these trees first to the test tree, and then to the
 release tree.  At first I replicated this in GIT, but then I realised
@@ -42,7 +42,7 @@ So here is the step-by-step guide how this all works for me.
 
 First create your work tree by cloning Linus's public tree:
 
- $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
+ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
 
 Change directory into the cloned tree you just created
 
@@ -52,7 +52,7 @@ Set up a remotes file so that you can fetch the latest from Linus' master
 branch into a local branch named "linus":
 
  $ cat > .git/remotes/linus
- URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Pull: master:linus
  ^D
 
@@ -92,6 +92,14 @@ These can be easily kept up to date by merging from the "linus" branch:
  $ git checkout test && git merge "Auto-update from upstream" test linus
  $ git checkout release && git merge "Auto-update from upstream" release linus
 
+Important note!  If you have any local changes in these branches, then
+this merge will create a commit object in the history (with no local
+changes git will simply do a "Fast forward" merge).  Many people dislike
+the "noise" that this creates in the Linux history, so you should avoid
+doing this capriciously in the "release" branch, as these noisy commits
+will become part of the permanent history when you ask Linus to pull
+from the release branch.
+
 Set up so that you can push upstream to your public tree (you need to
 log-in to the remote system and create an empty tree there before the
 first push).

Documentation/merge-options.txt

@@ -11,6 +11,6 @@
 	Use the given merge strategy; can be supplied more than
 	once to specify them in the order they should be tried.
 	If there is no `-s` option, a built-in list of strategies
-	is used instead (`git-merge-resolve` when merging a single
+	is used instead (`git-merge-recursive` when merging a single
 	head, `git-merge-octopus` otherwise).
 

Documentation/merge-strategies.txt

@@ -6,27 +6,27 @@ resolve::
 	and another branch you pulled from) using 3-way merge
 	algorithm.  It tries to carefully detect criss-cross
 	merge ambiguities and is considered generally safe and
-	fast.  This is the default merge strategy when pulling
-	one branch.
+	fast.
 
 recursive::
 	This can only resolve two heads using 3-way merge
 	algorithm.  When there are more than one common
 	ancestors that can be used for 3-way merge, it creates a
-	merged tree of the common ancestores and uses that as
+	merged tree of the common ancestors and uses that as
 	the reference tree for the 3-way merge.  This has been
 	reported to result in fewer merge conflicts without
 	causing mis-merges by tests done on actual merge commits
 	taken from Linux 2.6 kernel development history.
 	Additionally this can detect and handle merges involving
-	renames.
+	renames.  This is the default merge strategy when
+	pulling or merging one branch.
 
 octopus::
 	This resolves more than two-head case, but refuses to do
 	complex merge that needs manual resolution.  It is
 	primarily meant to be used for bundling topic branch
 	heads together.  This is the default merge strategy when
-	pulling more than one branch.
+	pulling or merging more than one branches.
 
 ours::
 	This resolves any number of heads, but the result of the

Documentation/pull-fetch-param.txt

@@ -1,48 +1,6 @@
 <repository>::
 	The "remote" repository that is the source of a fetch
-	or pull operation, or the destination of a push operation.
-	One of the following notations can be used
-	to name the remote repository:
-+
-===============================================================
-- Rsync URL:		rsync://remote.machine/path/to/repo.git/
-- HTTP(s) URL:		http://remote.machine/path/to/repo.git/
-- git URL:		git://remote.machine/path/to/repo.git/
-- ssh URL:		remote.machine:/path/to/repo.git/
-- Local directory:	/path/to/repo.git/
-===============================================================
-+
-In addition to the above, as a short-hand, the name of a
-file in `$GIT_DIR/remotes` directory can be given; the
-named file should be in the following format:
-+
-	URL: one of the above URL format
-	Push: <refspec>
-	Pull: <refspec>
-+
-When such a short-hand is specified in place of
-<repository> without <refspec> parameters on the command
-line, <refspec> specified on `Push:` lines or `Pull:`
-lines are used for `git-push` and `git-fetch`/`git-pull`,
-respectively.  Multiple `Push:` and and `Pull:` lines may
-be specified for additional branch mappings.
-+
-The name of a file in `$GIT_DIR/branches` directory can be
-specified as an older notation short-hand; the named
-file should contain a single line, a URL in one of the
-above formats, optionally followed by a hash `#` and the
-name of remote head (URL fragment notation).
-`$GIT_DIR/branches/<remote>` file that stores a <url>
-without the fragment is equivalent to have this in the
-corresponding file in the `$GIT_DIR/remotes/` directory.
-+
-	URL: <url>
-	Pull: refs/heads/master:<remote>
-+
-while having `<url>#<head>` is equivalent to
-+
-	URL: <url>
-	Pull: refs/heads/<head>:<remote>
+	or pull operation.  See the section <<URLS,GIT URLS>> below.
 
 <refspec>::
 	The canonical format of a <refspec> parameter is
@@ -50,17 +8,7 @@ while having `<url>#<head>` is equivalent to
 	by the source ref, followed by a colon `:`, followed by
 	the destination ref.
 +
-When used in `git-push`, the <src> side can be an
-arbitrary "SHA1 expression" that can be used as an
-argument to `git-cat-file -t`.  E.g. `master~4` (push
-four parents before the current master head).
-+
-For `git-push`, the local ref that matches <src> is used
-to fast forward the remote ref that matches <dst>.  If
-the optional plus `+` is used, the remote ref is updated
-even if it does not result in a fast forward update.
-+
-For `git-fetch` and `git-pull`, the remote ref that matches <src>
+The remote ref that matches <src>
 is fetched, and if <dst> is not empty string, the local
 ref that matches it is fast forwarded using <src>.
 Again, if the optional plus `+` is used, the local ref
@@ -93,7 +41,7 @@ on the remote branch, merge it into your development branch with
 `git pull . remote-B`, while you are on `my-B` branch.
 The common `Pull: master:origin` mapping of a remote `master`
 branch to a local `origin` branch, which is then merged to a
-ocal development branch, again typically named `master`, is made
+local development branch, again typically named `master`, is made
 when you run `git clone` for you to follow this pattern.
 +
 [NOTE]
@@ -114,11 +62,8 @@ is often useful.
 +
 Some short-cut notations are also supported.
 +
-* For backward compatibility, `tag` is almost ignored;
-  it just makes the following parameter <tag> to mean a
-  refspec `refs/tags/<tag>:refs/tags/<tag>`.
+* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`; 
+  it requests fetching everything up to the given tag.
 * A parameter <ref> without a colon is equivalent to
-  <ref>: when pulling/fetching, and <ref>`:`<ref> when
-  pushing.  That is, do not store it locally if
-  fetching, and update the same name if pushing.
-
+  <ref>: when pulling/fetching, so it merges <ref> into the current
+  branch without storing the remote branch anywhere locally

Documentation/repository-layout.txt

@@ -3,7 +3,7 @@ git repository layout
 
 You may find these things in your git repository (`.git`
 directory for a repository associated with your working tree, or
-`'project'.git` directory for a public 'naked' repository).
+`'project'.git` directory for a public 'bare' repository).
 
 objects::
 	Object store associated with this repository.  Usually
@@ -21,7 +21,7 @@ outside world but sometimes useful for private repository.
 . You can be using `objects/info/alternates` mechanism, or
 `$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanism to 'borrow'
 objects from other object stores.  A repository with this kind
-of incompete object store is not suitable to be published for
+of incomplete object store is not suitable to be published for
 use with dumb transports but otherwise is OK as long as
 `objects/info/alternates` points at the right object stores
 it borrows from.
@@ -73,7 +73,7 @@ HEAD::
 	A symlink of the form `refs/heads/'name'` to point at
 	the current branch, if exists.  It does not mean much if
 	the repository is not associated with any working tree
-	(i.e. 'naked' repository), but a valid git repository
+	(i.e. a 'bare' repository), but a valid git repository
 	*must* have such a symlink here.  It is legal if the
 	named branch 'name' does not (yet) exist.
 
@@ -92,7 +92,7 @@ hooks::
 
 index::
 	The current index file for the repository.  It is
-	usually not found in a naked repository.
+	usually not found in a bare repository.
 
 info::
 	Additional information about the repository is recorded
@@ -106,7 +106,7 @@ info/refs::
 	up-to-date if the repository is published for dumb
 	transports.  The `git-receive-pack` command, which is
 	run on a remote repository when you `git push` into it,
-	runs `hooks/update` hook to help you achive this.
+	runs `hooks/update` hook to help you achieve this.
 
 info/grafts::
 	This file records fake commit ancestry information, to

Documentation/sort_glossary.pl

@@ -42,7 +42,6 @@ sub no_spaces ($) {
 
 print 'GIT Glossary
 ============
-Aug 2005
 
 This list is sorted alphabetically:
 

Documentation/technical/pack-protocol.txt

@@ -1,3 +1,6 @@
+Pack transfer protocols
+=======================
+
 There are two Pack push-pull protocols.
 
 upload-pack (S) | fetch/clone-pack (C) protocol:

Documentation/urls.txt

@@ -0,0 +1,68 @@
+GIT URLS[[URLS]]
+----------------
+
+One of the following notations can be used
+to name the remote repository:
+
+===============================================================
+- rsync://host.xz/path/to/repo.git/
+- http://host.xz/path/to/repo.git/
+- https://host.xz/path/to/repo.git/
+- git://host.xz/path/to/repo.git/
+- git://host.xz/~user/path/to/repo.git/
+- ssh://host.xz/path/to/repo.git/
+- ssh://host.xz/~user/path/to/repo.git/
+- ssh://host.xz/~/path/to/repo.git
+===============================================================
+
+SSH Is the default transport protocol and also supports an
+scp-like syntax.  Both syntaxes support username expansion,
+as does the native git protocol. The following three are
+identical to the last three above, respectively:
+
+===============================================================
+- host.xz:/path/to/repo.git/
+- host.xz:~user/path/to/repo.git/
+- host.xz:path/to/repo.git
+===============================================================
+
+To sync with a local directory, use:
+
+===============================================================
+- /path/to/repo.git/
+===============================================================
+
+REMOTES
+-------
+
+In addition to the above, as a short-hand, the name of a
+file in `$GIT_DIR/remotes` directory can be given; the
+named file should be in the following format:
+
+	URL: one of the above URL format
+	Push: <refspec>
+	Pull: <refspec>
+
+Then such a short-hand is specified in place of
+<repository> without <refspec> parameters on the command
+line, <refspec> specified on `Push:` lines or `Pull:`
+lines are used for `git-push` and `git-fetch`/`git-pull`,
+respectively.  Multiple `Push:` and and `Pull:` lines may
+be specified for additional branch mappings.
+
+The name of a file in `$GIT_DIR/branches` directory can be
+specified as an older notation short-hand; the named
+file should contain a single line, a URL in one of the
+above formats, optionally followed by a hash `#` and the
+name of remote head (URL fragment notation).
+`$GIT_DIR/branches/<remote>` file that stores a <url>
+without the fragment is equivalent to have this in the
+corresponding file in the `$GIT_DIR/remotes/` directory.
+
+	URL: <url>
+	Pull: refs/heads/master:<remote>
+
+while having `<url>#<head>` is equivalent to
+
+	URL: <url>
+	Pull: refs/heads/<head>:<remote>

GIT-VERSION-GEN

@@ -0,0 +1,35 @@
+#!/bin/sh
+
+GVF=GIT-VERSION-FILE
+DEF_VER=v1.2.GIT
+
+# First try git-describe, then see if there is a version file
+# (included in release tarballs), then default
+if VN=$(git-describe --abbrev=4 HEAD 2>/dev/null); then
+	VN=$(echo "$VN" | sed -e 's/-/./g');
+else
+	VN=$(cat version) || VN="$DEF_VER"
+fi
+
+VN=$(expr "$VN" : v*'\(.*\)')
+
+dirty=$(sh -c 'git-diff-index --name-only HEAD' 2>/dev/null) || dirty=
+case "$dirty" in
+'')
+	;;
+*)
+	VN="$VN-dirty" ;;
+esac
+
+if test -r $GVF
+then
+	VC=$(sed -e 's/^GIT_VERSION = //' <$GVF)
+else
+	VC=unset
+fi
+test "$VN" = "$VC" || {
+	echo >&2 "GIT_VERSION = $VN"
+	echo "GIT_VERSION = $VN" >$GVF
+}
+
+

INSTALL

@@ -5,8 +5,8 @@ Normally you can just do "make" followed by "make install", and that
 will install the git programs in your own ~/bin/ directory.  If you want
 to do a global install, you can do
 
-	$ make prefix=/usr ;# as yourself
-	# make prefix=/usr install ;# as root
+	$ make prefix=/usr all doc ;# as yourself
+	# make prefix=/usr install install-doc ;# as root
 
 (or prefix=/usr/local, of course).  Just like any program suite
 that uses $prefix, the built results have some paths encoded,
@@ -87,3 +87,30 @@ Issues of note:
    have all the libraries/tools needed, or you may have
    necessary libraries at unusual locations.  Please look at the
    top of the Makefile to see what can be adjusted for your needs.
+   You can place local settings in config.mak and the Makefile
+   will include them.  Note that config.mak is not distributed;
+   the name is reserved for local settings.
+
+ - To build and install documentation suite, you need to have the
+   asciidoc/xmlto toolchain.  Alternatively, pre-formatted
+   documentation are available in "html" and "man" branches of the git
+   repository itself.  For example, you could:
+
+	$ mkdir manual && cd manual
+	$ git init-db
+	$ git clone-pack git://git.kernel.org/pub/scm/git/git.git man html |
+	  while read a b
+	  do
+	    echo $a >.git/$b
+	  done
+	$ cp .git/refs/heads/man .git/refs/heads/master
+	$ git checkout
+
+   to checkout the pre-built man pages.  Also in this repository:
+
+	$ git checkout html
+
+   would instead give you a copy of what you see at:
+
+	http://www.kernel.org/pub/software/scm/git/docs/
+

Makefile

@@ -1,3 +1,6 @@
+# The default target of this Makefile is...
+all:
+
 # Define MOZILLA_SHA1 environment variable when running make to make use of
 # a bundled SHA1 routine coming from Mozilla. It is GPL'd and should be fast
 # on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default
@@ -16,8 +19,18 @@
 # Define NO_EXPAT if you do not have expat installed.  git-http-push is
 # not built, and you cannot push using http:// and https:// transports.
 #
+# Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.
+#
+# Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks
+# d_type in struct dirent (latest Cygwin -- will be fixed soonish).
+#
 # Define NO_STRCASESTR if you don't have strcasestr.
 #
+# Define NO_SETENV if you don't have setenv in the C library.
+#
+# Define USE_SYMLINK_HEAD if you want .git/HEAD to be a symbolic link.
+# Don't enable it on Windows.
+#
 # Define PPC_SHA1 environment variable when running make to make use of
 # a bundled SHA1 routine optimized for PowerPC.
 #
@@ -37,6 +50,9 @@
 #
 # Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
 #
+# Define NO_SOCKADDR_STORAGE if your platform does not have struct
+# sockaddr_storage.
+#
 # Define COLLISION_CHECK below if you believe that SHA1's
 # 1461501637330902918203684832716283019655932542976 hashes do not give you
 # sufficient guarantee that no collisions between objects will ever happen.
@@ -50,7 +66,9 @@
 # Define USE_STDEV below if you want git to care about the underlying device
 # change being considered an inode change from the update-cache perspective.
 
-GIT_VERSION = 0.99.9j
+GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
+	@$(SHELL) ./GIT-VERSION-GEN
+-include GIT-VERSION-FILE
 
 # CFLAGS and LDFLAGS are for the users to override from the command line.
 
@@ -58,9 +76,11 @@ CFLAGS = -g -O2 -Wall
 LDFLAGS =
 ALL_CFLAGS = $(CFLAGS)
 ALL_LDFLAGS = $(LDFLAGS)
+STRIP ?= strip
 
 prefix = $(HOME)
 bindir = $(prefix)/bin
+gitexecdir = $(prefix)/bin
 template_dir = $(prefix)/share/git-core/templates/
 GIT_PYTHON_DIR = $(prefix)/share/git-core/python
 # DESTDIR=
@@ -84,10 +104,10 @@ SCRIPT_SH = \
 	git-cherry.sh git-clone.sh git-commit.sh \
 	git-count-objects.sh git-diff.sh git-fetch.sh \
 	git-format-patch.sh git-log.sh git-ls-remote.sh \
-	git-merge-one-file.sh git-octopus.sh git-parse-remote.sh \
+	git-merge-one-file.sh git-parse-remote.sh \
 	git-prune.sh git-pull.sh git-push.sh git-rebase.sh \
 	git-repack.sh git-request-pull.sh git-reset.sh \
-	git-resolve.sh git-revert.sh git-sh-setup.sh git-status.sh \
+	git-resolve.sh git-revert.sh git-sh-setup.sh \
 	git-tag.sh git-verify-tag.sh git-whatchanged.sh \
 	git-applymbox.sh git-applypatch.sh git-am.sh \
 	git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
@@ -96,18 +116,23 @@ SCRIPT_SH = \
 
 SCRIPT_PERL = \
 	git-archimport.perl git-cvsimport.perl git-relink.perl \
-	git-shortlog.perl git-fmt-merge-msg.perl \
+	git-shortlog.perl git-fmt-merge-msg.perl git-rerere.perl \
 	git-svnimport.perl git-mv.perl git-cvsexportcommit.perl
 
 SCRIPT_PYTHON = \
 	git-merge-recursive.py
 
+SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
+	  $(patsubst %.perl,%,$(SCRIPT_PERL)) \
+	  $(patsubst %.py,%,$(SCRIPT_PYTHON)) \
+	  git-cherry-pick git-show git-status
+
 # The ones that do not have to link with lcrypto nor lz.
 SIMPLE_PROGRAMS = \
 	git-get-tar-commit-id$X git-mailinfo$X git-mailsplit$X \
 	git-stripspace$X git-daemon$X
 
-# ... and all the rest
+# ... and all the rest that could be moved out of bindir to gitexecdir
 PROGRAMS = \
 	git-apply$X git-cat-file$X \
 	git-checkout-index$X git-clone-pack$X git-commit-tree$X \
@@ -125,44 +150,48 @@ PROGRAMS = \
 	git-unpack-objects$X git-update-index$X git-update-server-info$X \
 	git-upload-pack$X git-verify-pack$X git-write-tree$X \
 	git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
-	git-name-rev$X git-pack-redundant$X git-var$X $(SIMPLE_PROGRAMS)
+	git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X \
+	git-describe$X
+
+# what 'all' will build and 'install' will install, in gitexecdir
+ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
 
 # Backward compatibility -- to be removed after 1.0
 PROGRAMS += git-ssh-pull$X git-ssh-push$X
 
-GIT_LIST_TWEAK =
+# Set paths to tools early so that they can be used for version tests.
+ifndef SHELL_PATH
+	SHELL_PATH = /bin/sh
+endif
+ifndef PERL_PATH
+	PERL_PATH = /usr/bin/perl
+endif
+ifndef PYTHON_PATH
+	PYTHON_PATH = /usr/bin/python
+endif
 
 PYMODULES = \
 	gitMergeCommon.py
 
-ifdef WITH_OWN_SUBPROCESS_PY
-	PYMODULES += compat/subprocess.py
-endif
-
-ifdef WITH_SEND_EMAIL
-	SCRIPT_PERL += git-send-email.perl
-else
-	GIT_LIST_TWEAK += -e '/^send-email$$/d'
-endif
-
 LIB_FILE=libgit.a
 
 LIB_H = \
 	blob.h cache.h commit.h count-delta.h csum-file.h delta.h \
 	diff.h epoch.h object.h pack.h pkt-line.h quote.h refs.h \
-	run-command.h strbuf.h tag.h tree.h
+	run-command.h strbuf.h tag.h tree.h git-compat-util.h
 
 DIFF_OBJS = \
 	diff.o diffcore-break.o diffcore-order.o diffcore-pathspec.o \
-	diffcore-pickaxe.o diffcore-rename.o tree-diff.o
+	diffcore-pickaxe.o diffcore-rename.o tree-diff.o combine-diff.o
 
 LIB_OBJS = \
 	blob.o commit.o connect.o count-delta.o csum-file.o \
-	date.o diff-delta.o entry.o ident.o index.o \
+	date.o diff-delta.o entry.o exec_cmd.o ident.o index.o \
 	object.o pack-check.o patch-delta.o path.o pkt-line.o \
 	quote.o read-cache.o refs.o run-command.o \
 	server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
 	tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
+	fetch-clone.o \
 	$(DIFF_OBJS)
 
 LIBS = $(LIB_FILE)
@@ -184,6 +213,7 @@ shellquote = '$(call shq,$(1))'
 uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
 uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
 uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
+uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
 
 ifeq ($(uname_S),Darwin)
 	NEEDS_SSL_WITH_CRYPTO = YesPlease
@@ -201,16 +231,30 @@ ifeq ($(uname_S),SunOS)
 	NEEDS_LIBICONV = YesPlease
 	SHELL_PATH = /bin/bash
 	NO_STRCASESTR = YesPlease
+	ifeq ($(uname_R),5.8)
+		NO_UNSETENV = YesPlease
+		NO_SETENV = YesPlease
+	endif
 	INSTALL = ginstall
 	TAR = gtar
 	ALL_CFLAGS += -D__EXTENSIONS__
 endif
 ifeq ($(uname_O),Cygwin)
+	NO_D_TYPE_IN_DIRENT = YesPlease
+	NO_D_INO_IN_DIRENT = YesPlease
 	NO_STRCASESTR = YesPlease
 	NEEDS_LIBICONV = YesPlease
+	# There are conflicting reports about this.
+	# On some boxes NO_MMAP is needed, and not so elsewhere.
+	# Try uncommenting this if you see things break -- YMMV.
+	# NO_MMAP = YesPlease
 	NO_IPV6 = YesPlease
 	X = .exe
-	ALL_CFLAGS += -DUSE_SYMLINK_HEAD=0
+endif
+ifeq ($(uname_S),FreeBSD)
+	NEEDS_LIBICONV = YesPlease
+	ALL_CFLAGS += -I/usr/local/include
+	ALL_LDFLAGS += -L/usr/local/lib
 endif
 ifeq ($(uname_S),OpenBSD)
 	NO_STRCASESTR = YesPlease
@@ -223,12 +267,28 @@ ifeq ($(uname_S),NetBSD)
 	ALL_CFLAGS += -I/usr/pkg/include
 	ALL_LDFLAGS += -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib
 endif
+ifeq ($(uname_S),AIX)
+	NO_STRCASESTR=YesPlease
+	NEEDS_LIBICONV=YesPlease
+endif
 ifneq (,$(findstring arm,$(uname_M)))
 	ARM_SHA1 = YesPlease
 endif
 
 -include config.mak
 
+ifdef WITH_OWN_SUBPROCESS_PY
+	PYMODULES += compat/subprocess.py
+else
+	ifneq ($(shell $(PYTHON_PATH) -c 'import subprocess;print"OK"' 2>/dev/null),OK)
+		PYMODULES += compat/subprocess.py
+	endif
+endif
+
+ifdef WITH_SEND_EMAIL
+	SCRIPT_PERL += git-send-email.perl
+endif
+
 ifndef NO_CURL
 	ifdef CURLDIR
 		# This is still problematic -- gcc does not always want -R.
@@ -238,20 +298,13 @@ ifndef NO_CURL
 		CURL_LIBCURL = -lcurl
 	endif
 	PROGRAMS += git-http-fetch$X
+	curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
+	ifeq "$(curl_check)" "070908"
 		ifndef NO_EXPAT
 			EXPAT_LIBEXPAT = -lexpat
 			PROGRAMS += git-http-push$X
 		endif
-endif
-
-ifndef SHELL_PATH
-	SHELL_PATH = /bin/sh
-endif
-ifndef PERL_PATH
-	PERL_PATH = /usr/bin/perl
-endif
-ifndef PYTHON_PATH
-	PYTHON_PATH = /usr/bin/python
+	endif
 endif
 
 ifndef NO_OPENSSL
@@ -294,16 +347,37 @@ ifdef NEEDS_NSL
 	LIBS += -lnsl
 	SIMPLE_LIB += -lnsl
 endif
+ifdef NO_D_TYPE_IN_DIRENT
+	ALL_CFLAGS += -DNO_D_TYPE_IN_DIRENT
+endif
+ifdef NO_D_INO_IN_DIRENT
+	ALL_CFLAGS += -DNO_D_INO_IN_DIRENT
+endif
 ifdef NO_STRCASESTR
-	ALL_CFLAGS += -Dstrcasestr=gitstrcasestr -DNO_STRCASESTR=1
-	LIB_OBJS += compat/strcasestr.o
+	COMPAT_CFLAGS += -DNO_STRCASESTR
+	COMPAT_OBJS += compat/strcasestr.o
+endif
+ifdef NO_SETENV
+	COMPAT_CFLAGS += -DNO_SETENV
+	COMPAT_OBJS += compat/setenv.o
+endif
+ifdef NO_SETENV
+	COMPAT_CFLAGS += -DNO_UNSETENV
+	COMPAT_OBJS += compat/unsetenv.o
 endif
 ifdef NO_MMAP
-	ALL_CFLAGS += -Dmmap=gitfakemmap -Dmunmap=gitfakemunmap -DNO_MMAP
-	LIB_OBJS += compat/mmap.o
+	COMPAT_CFLAGS += -DNO_MMAP
+	COMPAT_OBJS += compat/mmap.o
 endif
 ifdef NO_IPV6
-	ALL_CFLAGS += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in
+	ALL_CFLAGS += -DNO_IPV6
+endif
+ifdef NO_SOCKADDR_STORAGE
+ifdef NO_IPV6
+	ALL_CFLAGS += -Dsockaddr_storage=sockaddr_in
+else
+	ALL_CFLAGS += -Dsockaddr_storage=sockaddr_in6
+endif
 endif
 
 ifdef PPC_SHA1
@@ -324,27 +398,24 @@ endif
 endif
 endif
 
-ALL_CFLAGS += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER))
-
-SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
-	  $(patsubst %.perl,%,$(SCRIPT_PERL)) \
-	  $(patsubst %.py,%,$(SCRIPT_PYTHON)) \
-	  gitk git-cherry-pick
-
+ALL_CFLAGS += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER)) $(COMPAT_CFLAGS)
+LIB_OBJS += $(COMPAT_OBJS)
 export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
 ### Build rules
 
-all: $(PROGRAMS) $(SCRIPTS) git
+all: $(ALL_PROGRAMS) git$X gitk
 
 all:
 	$(MAKE) -C templates
 
-# Only use $(CFLAGS). We don't need anything else.
-git: git.c Makefile
-	$(CC) -DGIT_EXEC_PATH='"$(bindir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
-		$(CFLAGS) $@.c -o $@
+strip: $(PROGRAMS) git$X
+	$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
 
-$(filter-out git,$(patsubst %.sh,%,$(SCRIPT_SH))) : % : %.sh
+git$X: git.c $(LIB_FILE)
+	$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
+		$(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE)
+
+$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
 	rm -f $@
 	sed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \
 	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
@@ -369,11 +440,26 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
 git-cherry-pick: git-revert
 	cp $< $@
 
+git-show: git-whatchanged
+	cp $< $@
+
+git-status: git-commit
+	cp $< $@
+
+# These can record GIT_VERSION
+git$X git.spec \
+	$(patsubst %.sh,%,$(SCRIPT_SH)) \
+	$(patsubst %.perl,%,$(SCRIPT_PERL)) \
+	$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
+	: GIT-VERSION-FILE
+
 %.o: %.c
 	$(CC) -o $*.o -c $(ALL_CFLAGS) $<
 %.o: %.S
 	$(CC) -o $*.o -c $(ALL_CFLAGS) $<
 
+exec_cmd.o: ALL_CFLAGS += -DGIT_EXEC_PATH=\"$(gitexecdir)\"
+
 git-%$X: %.o $(LIB_FILE)
 	$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
 
@@ -383,7 +469,8 @@ $(SIMPLE_PROGRAMS) : git-%$X : %.o
 	$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
 		$(LIB_FILE) $(SIMPLE_LIB)
 
-git-http-fetch$X: fetch.o
+git-http-fetch$X: fetch.o http.o
+git-http-push$X: http.o
 git-local-fetch$X: fetch.o
 git-ssh-fetch$X: rsh.o fetch.o
 git-ssh-upload$X: rsh.o
@@ -421,15 +508,17 @@ test-delta$X: test-delta.c diff-delta.o patch-delta.o
 	$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $^
 
 check:
-	for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
+	for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
 
 
 
 ### Installation rules
 
-install: $(PROGRAMS) $(SCRIPTS) git
+install: all
 	$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
-	$(INSTALL) git $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(bindir))
+	$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitexecdir))
+	$(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(gitexecdir))
+	$(INSTALL) git$X gitk $(call shellquote,$(DESTDIR)$(bindir))
 	$(MAKE) -C templates install
 	$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
 	$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
@@ -442,7 +531,7 @@ install-doc:
 
 ### Maintainer's dist rules
 
-git.spec: git.spec.in Makefile
+git.spec: git.spec.in
 	sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@
 
 GIT_TARNAME=git-$(GIT_VERSION)
@@ -450,29 +539,28 @@ dist: git.spec git-tar-tree
 	./git-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME).tar
 	@mkdir -p $(GIT_TARNAME)
 	@cp git.spec $(GIT_TARNAME)
-	$(TAR) rf $(GIT_TARNAME).tar $(GIT_TARNAME)/git.spec
+	@echo $(GIT_VERSION) > $(GIT_TARNAME)/version
+	$(TAR) rf $(GIT_TARNAME).tar \
+		$(GIT_TARNAME)/git.spec $(GIT_TARNAME)/version
 	@rm -rf $(GIT_TARNAME)
 	gzip -f -9 $(GIT_TARNAME).tar
 
 rpm: dist
 	$(RPMBUILD) -ta $(GIT_TARNAME).tar.gz
 
-deb: dist
-	rm -rf $(GIT_TARNAME)
-	$(TAR) zxf $(GIT_TARNAME).tar.gz
-	dpkg-source -b $(GIT_TARNAME)
-	cd $(GIT_TARNAME) && fakeroot debian/rules binary
-
 ### Cleaning rules
 
 clean:
-	rm -f *.o mozilla-sha1/*.o ppc/*.o compat/*.o $(PROGRAMS) $(LIB_FILE)
-	rm -f $(filter-out gitk,$(SCRIPTS))
-	rm -f *.spec *.pyc *.pyo
+	rm -f *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o $(LIB_FILE)
+	rm -f $(ALL_PROGRAMS) git$X
+	rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo
 	rm -rf $(GIT_TARNAME)
 	rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
-	rm -f git-core_$(GIT_VERSION)-*.dsc
-	rm -f git-*_$(GIT_VERSION)-*.deb
 	$(MAKE) -C Documentation/ clean
 	$(MAKE) -C templates clean
 	$(MAKE) -C t/ clean
+	rm -f GIT-VERSION-FILE
+
+.PHONY: all install clean strip
+.PHONY: .FORCE-GIT-VERSION-FILE
+

README

@@ -35,7 +35,7 @@ the object (i.e. how it is used, and how it can refer to other
 objects).  There are currently four different object types: "blob",
 "tree", "commit" and "tag".
 
-A "blob" object cannot refer to any other object, and is, like the tag
+A "blob" object cannot refer to any other object, and is, like the type
 implies, a pure storage object containing some user data.  It is used to
 actually store the file data, i.e. a blob object is associated with some
 particular version of some file. 
@@ -64,7 +64,7 @@ symbolic name (of course!) and, optionally, a signature.
 
 Regardless of object type, all objects share the following
 characteristics: they are all deflated with zlib, and have a header
-that not only specifies their tag, but also provides size information
+that not only specifies their type, but also provides size information
 about the data in the object.  It's worth noting that the SHA1 hash
 that is used to name the object is the hash of the original data
 plus this header, so `sha1sum` 'file' does not match the object name
@@ -76,7 +76,7 @@ As a result, the general consistency of an object can always be tested
 independently of the contents or the type of the object: all objects can
 be validated by verifying that (a) their hashes match the content of the
 file and (b) the object successfully inflates to a stream of bytes that
-forms a sequence of <ascii tag without space> + <space> + <ascii decimal
+forms a sequence of <ascii type without space> + <space> + <ascii decimal
 size> + <byte\0> + <binary object data>. 
 
 The structured objects can further have their structure and
@@ -297,7 +297,7 @@ will not normally add totally new entries or remove old entries,
 i.e. it will normally just update existing cache entries.
 
 To tell git that yes, you really do realize that certain files no
-longer exist in the archive, or that new files should be added, you
+longer exist, or that new files should be added, you
 should use the `--remove` and `--add` flags respectively.
 
 NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
@@ -515,8 +515,11 @@ index file, and you can just write the result out with
 Historical note.  We did not have `-u` facility when this
 section was first written, so we used to warn that
 the merge is done in the index file, not in your
-working directory, and your working directory will no longer match your
-index.
+working tree, and your working tree will not match your
+index after this step.
+This is no longer true.  The above command, thanks to `-u`
+option, updates your working tree with the merge results for
+paths that have been trivially merged.
 
 
 8) Merging multiple trees, continued
@@ -579,7 +582,7 @@ The above is the description of a git merge at the lowest level,
 to help you understand what conceptually happens under the hood.
 In practice, nobody, not even git itself, uses three `git-cat-file`
 for this.  There is `git-merge-index` program that extracts the
-stages to temporary files and calls a `merge` script on it
+stages to temporary files and calls a "merge" script on it:
 
 	git-merge-index git-merge-one-file hello.c
 

apply.c

@@ -16,6 +16,10 @@
 //  --numstat does numeric diffstat, and doesn't actually apply
 //  --index-info shows the old and new index info for paths if available.
 //
+static const char *prefix;
+static int prefix_length = -1;
+
+static int p_value = 1;
 static int allow_binary_replacement = 0;
 static int check_index = 0;
 static int write_index = 0;
@@ -28,7 +32,7 @@ static int no_add = 0;
 static int show_index_info = 0;
 static int line_termination = '\n';
 static const char apply_usage[] =
-"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [-z] <patch>...";
+"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [-z] [-pNUM] <patch>...";
 
 /*
  * For "diff-stat" like behaviour, we keep track of the biggest change
@@ -81,14 +85,11 @@ static void *read_patch_file(int fd, unsigned long *sizep)
 			buffer = xrealloc(buffer, alloc);
 			nr = alloc - size;
 		}
-		nr = read(fd, buffer + size, nr);
+		nr = xread(fd, buffer + size, nr);
 		if (!nr)
 			break;
-		if (nr < 0) {
-			if (errno == EAGAIN)
-				continue;
+		if (nr < 0)
 			die("git-apply: read returned %s", strerror(errno));
-		}
 		size += nr;
 	}
 	*sizep = size;
@@ -217,7 +218,6 @@ static char * find_name(const char *line, char *def, int p_value, int terminate)
  */
 static void parse_traditional_patch(const char *first, const char *second, struct patch *patch)
 {
-	int p_value = 1;
 	char *name;
 
 	first += 4;	// skip "--- "
@@ -893,12 +893,24 @@ static int parse_chunk(char *buffer, unsigned long size, struct patch *patch)
 	patchsize = parse_single_patch(buffer + offset + hdrsize, size - offset - hdrsize, patch);
 
 	if (!patchsize) {
-		static const char binhdr[] = "Binary files ";
+		static const char *binhdr[] = {
+			"Binary files ",
+			"Files ",
+			NULL,
+		};
+		int i;
+		int hd = hdrsize + offset;
+		unsigned long llen = linelen(buffer + hd, size - hd);
 
-		if (sizeof(binhdr) - 1 < size - offset - hdrsize &&
-		    !memcmp(binhdr, buffer + hdrsize + offset,
-			    sizeof(binhdr)-1))
+		if (!memcmp(" differ\n", buffer + hd + llen - 8, 8))
+			for (i = 0; binhdr[i]; i++) {
+				int len = strlen(binhdr[i]);
+				if (len < size - hd &&
+				    !memcmp(binhdr[i], buffer + hd, len)) {
 					patch->is_binary = 1;
+					break;
+				}
+			}
 
 		/* Empty patch cannot be applied if:
 		 * - it is a binary patch and we do not do binary_replace, or
@@ -991,13 +1003,8 @@ static int read_old_data(struct stat *st, const char *path, void *buf, unsigned
 			return error("unable to open %s", path);
 		got = 0;
 		for (;;) {
-			int ret = read(fd, buf + got, size - got);
-			if (ret < 0) {
-				if (errno == EAGAIN)
-					continue;
-				break;
-			}
-			if (!ret)
+			int ret = xread(fd, buf + got, size - got);
+			if (ret <= 0)
 				break;
 			got += ret;
 		}
@@ -1557,40 +1564,19 @@ static void add_index_file(const char *path, unsigned mode, void *buf, unsigned
 		die("unable to add cache entry for %s", path);
 }
 
-static void create_subdirectories(const char *path)
-{
-	int len = strlen(path);
-	char *buf = xmalloc(len + 1);
-	const char *slash = path;
-
-	while ((slash = strchr(slash+1, '/')) != NULL) {
-		len = slash - path;
-		memcpy(buf, path, len);
-		buf[len] = 0;
-		if (mkdir(buf, 0777) < 0) {
-			if (errno != EEXIST)
-				break;
-		}
-	}
-	free(buf);
-}
-
 static int try_create_file(const char *path, unsigned int mode, const char *buf, unsigned long size)
 {
 	int fd;
 
 	if (S_ISLNK(mode))
 		return symlink(buf, path);
-	fd = open(path, O_CREAT | O_EXCL | O_WRONLY | O_TRUNC, (mode & 0100) ? 0777 : 0666);
+	fd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666);
 	if (fd < 0)
 		return -1;
 	while (size) {
-		int written = write(fd, buf, size);
-		if (written < 0) {
-			if (errno == EINTR || errno == EAGAIN)
-				continue;
+		int written = xwrite(fd, buf, size);
+		if (written < 0)
 			die("writing file %s: %s", path, strerror(errno));
-		}
 		if (!written)
 			die("out of space writing file %s", path);
 		buf += written;
@@ -1606,13 +1592,14 @@ static int try_create_file(const char *path, unsigned int mode, const char *buf,
  * which is true 99% of the time anyway. If they don't,
  * we create them and try again.
  */
-static void create_one_file(const char *path, unsigned mode, const char *buf, unsigned long size)
+static void create_one_file(char *path, unsigned mode, const char *buf, unsigned long size)
 {
 	if (!try_create_file(path, mode, buf, size))
 		return;
 
 	if (errno == ENOENT) {
-		create_subdirectories(path);
+		if (safe_create_leading_directories(path))
+			return;
 		if (!try_create_file(path, mode, buf, size))
 			return;
 	}
@@ -1631,6 +1618,7 @@ static void create_one_file(const char *path, unsigned mode, const char *buf, un
 			}
 			if (errno != EEXIST)
 				break;
+			++nr;
 		}
 	}
 	die("unable to write file %s mode %o", path, mode);
@@ -1638,7 +1626,7 @@ static void create_one_file(const char *path, unsigned mode, const char *buf, un
 
 static void create_file(struct patch *patch)
 {
-	const char *path = patch->new_name;
+	char *path = patch->new_name;
 	unsigned mode = patch->new_mode;
 	unsigned long size = patch->resultsize;
 	char *buf = patch->result;
@@ -1694,6 +1682,12 @@ static int use_patch(struct patch *p)
 			return 0;
 		x = x->next;
 	}
+	if (0 < prefix_length) {
+		int pathlen = strlen(pathname);
+		if (pathlen <= prefix_length ||
+		    memcmp(prefix, pathname, prefix_length))
+			return 0;
+	}
 	return 1;
 }
 
@@ -1788,6 +1782,10 @@ int main(int argc, char **argv)
 			excludes = x;
 			continue;
 		}
+		if (!strncmp(arg, "-p", 2)) {
+			p_value = atoi(arg + 2);
+			continue;
+		}
 		if (!strcmp(arg, "--no-add")) {
 			no_add = 1;
 			continue;
@@ -1833,6 +1831,15 @@ int main(int argc, char **argv)
 			line_termination = 0;
 			continue;
 		}
+
+		if (check_index && prefix_length < 0) {
+			prefix = setup_git_directory();
+			prefix_length = prefix ? strlen(prefix) : 0;
+			git_config(git_default_config);
+		}
+		if (0 < prefix_length)
+			arg = prefix_filename(prefix, prefix_length, arg);
+
 		fd = open(arg, O_RDONLY);
 		if (fd < 0)
 			usage(apply_usage);

blob.c

@@ -1,5 +1,5 @@
-#include "blob.h"
 #include "cache.h"
+#include "blob.h"
 #include <stdlib.h>
 
 const char *blob_type = "blob";

cache.h

@@ -1,23 +1,7 @@
 #ifndef CACHE_H
 #define CACHE_H
 
-#include <unistd.h>
-#include <stdio.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <stddef.h>
-#include <stdlib.h>
-#include <stdarg.h>
-#include <string.h>
-#include <errno.h>
-#include <limits.h>
-#ifndef NO_MMAP
-#include <sys/mman.h>
-#endif
-#include <sys/param.h>
-#include <netinet/in.h>
-#include <sys/types.h>
-#include <dirent.h>
+#include "git-compat-util.h"
 
 #include SHA1_HEADER
 #include <zlib.h>
@@ -26,9 +10,13 @@
 #define deflateBound(c,s)  ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
 #endif
 
-#ifdef DT_UNKNOWN
+#if defined(DT_UNKNOWN) && !NO_D_TYPE_IN_DIRENT
 #define DTYPE(de)	((de)->d_type)
 #else
+#undef DT_UNKNOWN
+#undef DT_DIR
+#undef DT_REG
+#undef DT_LNK
 #define DT_UNKNOWN	0
 #define DT_DIR		1
 #define DT_REG		2
@@ -36,15 +24,6 @@
 #define DTYPE(de)	DT_UNKNOWN
 #endif
 
-#ifdef __GNUC__
-#define NORETURN __attribute__((__noreturn__))
-#else
-#define NORETURN
-#ifndef __attribute__
-#define __attribute__(x)
-#endif
-#endif
-
 /*
  * Intensive research over the course of many years has shown that
  * port 9418 is totally unused by anything else. Or
@@ -106,7 +85,7 @@ struct cache_entry {
 	unsigned int ce_size;
 	unsigned char sha1[20];
 	unsigned short ce_flags;
-	char name[0];
+	char name[FLEX_ARRAY]; /* more */
 };
 
 #define CE_NAMEMASK  (0x0fff)
@@ -147,8 +126,10 @@ extern char *get_graft_file(void);
 #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
 
 extern const char **get_pathspec(const char *prefix, const char **pathspec);
+extern const char *setup_git_directory_gently(int *);
 extern const char *setup_git_directory(void);
 extern const char *prefix_path(const char *prefix, int len, const char *path);
+extern const char *prefix_filename(const char *prefix, int len, const char *path);
 
 #define alloc_nr(x) (((x)+16)*3/2)
 
@@ -167,6 +148,7 @@ extern int ce_match_stat(struct cache_entry *ce, struct stat *st);
 extern int ce_modified(struct cache_entry *ce, struct stat *st);
 extern int ce_path_match(const struct cache_entry *ce, const char **pathspec);
 extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type);
+extern int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object);
 extern int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object);
 extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
 
@@ -181,6 +163,11 @@ extern void rollback_index_file(struct cache_file *);
 extern int trust_executable_bit;
 extern int only_use_symrefs;
 extern int diff_rename_limit_default;
+extern int shared_repository;
+
+#define GIT_REPO_VERSION 0
+extern int repository_format_version;
+extern int check_repository_format(void);
 
 #define MTIME_CHANGED	0x0001
 #define CTIME_CHANGED	0x0002
@@ -201,8 +188,10 @@ extern const unsigned char null_sha1[20];
 
 int git_mkstemp(char *path, size_t n, const char *template);
 
+int adjust_shared_perm(const char *path);
 int safe_create_leading_directories(char *path);
 char *safe_strncpy(char *, const char *, size_t);
+char *enter_repo(char *path, int strict);
 
 /* Read and unpack a sha1 file into memory, write memory to a sha1 file */
 extern int unpack_sha1_header(z_stream *stream, void *map, unsigned long mapsize, void *buffer, unsigned long size);
@@ -220,9 +209,6 @@ extern char *write_sha1_file_prepare(void *buf,
 
 extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned long size, const char *type);
 
-/* Read a tree into the cache */
-extern int read_tree(void *buffer, unsigned long size, int stage, const char **paths);
-
 extern int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer,
 			      size_t bufsize, size_t *bufposn);
 extern int write_sha1_to_fd(int fd, const unsigned char *sha1);
@@ -235,6 +221,9 @@ extern int has_pack_file(const unsigned char *sha1);
 extern int has_pack_index(const unsigned char *sha1);
 
 /* Convert to/from hex/sha1 representation */
+#define MINIMUM_ABBREV 4
+#define DEFAULT_ABBREV 7
+
 extern int get_sha1(const char *str, unsigned char *sha1);
 extern int get_sha1_hex(const char *hex, unsigned char *sha1);
 extern char *sha1_to_hex(const unsigned char *sha1);	/* static buffer result! */
@@ -243,11 +232,6 @@ extern const char *resolve_ref(const char *path, unsigned char *sha1, int);
 extern int create_symref(const char *git_HEAD, const char *refs_heads_master);
 extern int validate_symref(const char *git_HEAD);
 
-/* General helper functions */
-extern void usage(const char *err) NORETURN;
-extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
-extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
-
 extern int base_name_compare(const char *name1, int len1, int mode1, const char *name2, int len2, int mode2);
 extern int cache_name_compare(const char *name1, int len1, const char *name2, int len2);
 
@@ -259,35 +243,11 @@ extern void *read_object_with_reference(const unsigned char *sha1,
 const char *show_date(unsigned long time, int timezone);
 int parse_date(const char *date, char *buf, int bufsize);
 void datestamp(char *buf, int bufsize);
+unsigned long approxidate(const char *);
 
 extern int setup_ident(void);
-extern char *get_ident(const char *name, const char *email, const char *date_str);
-extern char *git_author_info(void);
-extern char *git_committer_info(void);
-
-static inline void *xmalloc(size_t size)
-{
-	void *ret = malloc(size);
-	if (!ret)
-		die("Out of memory, malloc failed");
-	return ret;
-}
-
-static inline void *xrealloc(void *ptr, size_t size)
-{
-	void *ret = realloc(ptr, size);
-	if (!ret)
-		die("Out of memory, realloc failed");
-	return ret;
-}
-
-static inline void *xcalloc(size_t nmemb, size_t size)
-{
-	void *ret = calloc(nmemb, size);
-	if (!ret)
-		die("Out of memory, calloc failed");
-	return ret;
-}
+extern const char *git_author_info(void);
+extern const char *git_committer_info(void);
 
 struct checkout {
 	const char *base_dir;
@@ -303,7 +263,7 @@ extern int checkout_entry(struct cache_entry *ce, struct checkout *state);
 extern struct alternate_object_database {
 	struct alternate_object_database *next;
 	char *name;
-	char base[0]; /* more */
+	char base[FLEX_ARRAY]; /* more */
 } *alt_odb_list;
 extern void prepare_alt_odb(void);
 
@@ -317,7 +277,8 @@ extern struct packed_git {
 	unsigned int pack_use_cnt;
 	int pack_local;
 	unsigned char sha1[20];
-	char pack_name[0]; /* something like ".git/objects/pack/xxxxx.pack" */
+	/* something like ".git/objects/pack/xxxxx.pack" */
+	char pack_name[FLEX_ARRAY]; /* more */
 } *packed_git;
 
 struct pack_entry {
@@ -332,7 +293,7 @@ struct ref {
 	unsigned char new_sha1[20];
 	unsigned char force;
 	struct ref *peer_ref; /* when renaming */
-	char name[0];
+	char name[FLEX_ARRAY]; /* more */
 };
 
 extern int git_connect(int fd[2], char *url, const char *prog);
@@ -366,55 +327,27 @@ extern void packed_object_info_detail(struct pack_entry *, char *, unsigned long
 /* Dumb servers support */
 extern int update_server_info(int);
 
-#ifdef NO_MMAP
-
-#ifndef PROT_READ
-#define PROT_READ 1
-#define PROT_WRITE 2
-#define MAP_PRIVATE 1
-#define MAP_FAILED ((void*)-1)
-#endif
-
-extern void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
-extern int gitfakemunmap(void *start, size_t length);
-
-#endif
-
 typedef int (*config_fn_t)(const char *, const char *);
 extern int git_default_config(const char *, const char *);
+extern int git_config_from_file(config_fn_t fn, const char *);
 extern int git_config(config_fn_t fn);
 extern int git_config_int(const char *, const char *);
 extern int git_config_bool(const char *, const char *);
+extern int git_config_set(const char *, const char *);
+extern int git_config_set_multivar(const char *, const char *, const char *, int);
+extern int check_repository_format_version(const char *var, const char *value);
 
 #define MAX_GITNAME (1000)
 extern char git_default_email[MAX_GITNAME];
 extern char git_default_name[MAX_GITNAME];
 
-/* Sane ctype - no locale, and works with signed chars */
-#undef isspace
-#undef isdigit
-#undef isalpha
-#undef isalnum
-#undef tolower
-#undef toupper
-extern unsigned char sane_ctype[256];
-#define GIT_SPACE 0x01
-#define GIT_DIGIT 0x02
-#define GIT_ALPHA 0x04
-#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
-#define isspace(x) sane_istest(x,GIT_SPACE)
-#define isdigit(x) sane_istest(x,GIT_DIGIT)
-#define isalpha(x) sane_istest(x,GIT_ALPHA)
-#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
-#define tolower(x) sane_case((unsigned char)(x), 0x20)
-#define toupper(x) sane_case((unsigned char)(x), 0)
-
-static inline int sane_case(int x, int high)
-{
-	if (sane_istest(x, GIT_ALPHA))
-		x = (x & ~0x20) | high;
-	return x;
-}
+#define MAX_ENCODING_LENGTH 64
+extern char git_commit_encoding[MAX_ENCODING_LENGTH];
 
 extern int copy_fd(int ifd, int ofd);
+
+/* Finish off pack transfer receiving end */
+extern int receive_unpack_pack(int fd[2], const char *me, int quiet);
+extern int receive_keep_pack(int fd[2], const char *me, int quiet);
+
 #endif /* CACHE_H */

cat-file.c

@@ -11,37 +11,52 @@ int main(int argc, char **argv)
 	char type[20];
 	void *buf;
 	unsigned long size;
+	int opt;
 
 	setup_git_directory();
 	if (argc != 3 || get_sha1(argv[2], sha1))
-		usage("git-cat-file [-t | -s | <type>] <sha1>");
+		usage("git-cat-file [-t|-s|-e|<type>] <sha1>");
 
-	if (!strcmp("-t", argv[1]) || !strcmp("-s", argv[1])) {
-		if (!sha1_object_info(sha1, type,
-				      argv[1][1] == 's' ? &size : NULL)) {
-			switch (argv[1][1]) {
-			case 't':
-				printf("%s\n", type);
-				break;
-			case 's':
-				printf("%lu\n", size);
-				break;
+	opt = 0;
+	if ( argv[1][0] == '-' ) {
+		opt = argv[1][1];
+		if ( !opt || argv[1][2] )
+			opt = -1; /* Not a single character option */
 	}
+
+	buf = NULL;
+	switch (opt) {
+	case 't':
+		if (!sha1_object_info(sha1, type, NULL)) {
+			printf("%s\n", type);
 			return 0;
 		}
-		buf = NULL;
-	} else {
+		break;
+
+	case 's':
+		if (!sha1_object_info(sha1, type, &size)) {
+			printf("%lu\n", size);
+			return 0;
+		}
+		break;
+
+	case 'e':
+		return !has_sha1_file(sha1);
+
+	case 0:
 		buf = read_object_with_reference(sha1, argv[1], &size, NULL);
+		break;
+
+	default:
+		die("git-cat-file: unknown option: %s\n", argv[1]);
 	}
 
 	if (!buf)
 		die("git-cat-file %s: bad file", argv[2]);
 
 	while (size > 0) {
-		long ret = write(1, buf, size);
+		long ret = xwrite(1, buf, size);
 		if (ret < 0) {
-			if (errno == EAGAIN)
-				continue;
 			/* Ignore epipe */
 			if (errno == EPIPE)
 				break;

checkout-index.c

@@ -34,6 +34,10 @@
  */
 #include "cache.h"
 
+static const char *prefix;
+static int prefix_length;
+static int checkout_stage; /* default to checkout stage0 */
+
 static struct checkout state = {
 	.base_dir = "",
 	.base_dir_len = 0,
@@ -45,20 +49,36 @@ static struct checkout state = {
 
 static int checkout_file(const char *name)
 {
-	int pos = cache_name_pos(name, strlen(name));
-	if (pos < 0) {
-		if (!state.quiet) {
+	int namelen = strlen(name);
+	int pos = cache_name_pos(name, namelen);
+	int has_same_name = 0;
+
+	if (pos < 0)
 		pos = -pos - 1;
-			fprintf(stderr,
-				"git-checkout-index: %s is %s.\n",
-				name,
-				(pos < active_nr &&
-				 !strcmp(active_cache[pos]->name, name)) ?
-				"unmerged" : "not in the cache");
+
+	while (pos < active_nr) {
+		struct cache_entry *ce = active_cache[pos];
+		if (ce_namelen(ce) != namelen ||
+		    memcmp(ce->name, name, namelen))
+			break;
+		has_same_name = 1;
+		if (checkout_stage == ce_stage(ce))
+			return checkout_entry(ce, &state);
+		pos++;
+	}
+
+	if (!state.quiet) {
+		fprintf(stderr, "git-checkout-index: %s ", name);
+		if (!has_same_name)
+			fprintf(stderr, "is not in the cache");
+		else if (checkout_stage)
+			fprintf(stderr, "does not exist at stage %d",
+				checkout_stage);
+		else
+			fprintf(stderr, "is unmerged");
+		fputc('\n', stderr);
 	}
 	return -1;
-	}
-	return checkout_entry(active_cache[pos], &state);
 }
 
 static int checkout_all(void)
@@ -67,7 +87,11 @@ static int checkout_all(void)
 
 	for (i = 0; i < active_nr ; i++) {
 		struct cache_entry *ce = active_cache[i];
-		if (ce_stage(ce))
+		if (ce_stage(ce) != checkout_stage)
+			continue;
+		if (prefix && *prefix &&
+		    (ce_namelen(ce) <= prefix_length ||
+		     memcmp(prefix, ce->name, prefix_length)))
 			continue;
 		if (checkout_entry(ce, &state) < 0)
 			errs++;
@@ -81,7 +105,7 @@ static int checkout_all(void)
 }
 
 static const char checkout_cache_usage[] =
-"git-checkout-index [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] [--] <file>...";
+"git-checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]] [--prefix=<string>] [--] <file>...";
 
 static struct cache_file cache_file;
 
@@ -91,6 +115,9 @@ int main(int argc, char **argv)
 	int newfd = -1;
 	int all = 0;
 
+	prefix = setup_git_directory();
+	prefix_length = prefix ? strlen(prefix) : 0;
+
 	if (read_cache() < 0) {
 		die("invalid cache");
 	}
@@ -128,11 +155,19 @@ int main(int argc, char **argv)
 				die("cannot open index.lock file.");
 			continue;
 		}
-		if (!memcmp(arg, "--prefix=", 9)) {
+		if (!strncmp(arg, "--prefix=", 9)) {
 			state.base_dir = arg+9;
 			state.base_dir_len = strlen(state.base_dir);
 			continue;
 		}
+		if (!strncmp(arg, "--stage=", 8)) {
+			int ch = arg[8];
+			if ('1' <= ch && ch <= '3')
+				checkout_stage = arg[8] - '0';
+			else
+				die("stage should be between 1 and 3");
+			continue;
+		}
 		if (arg[0] == '-')
 			usage(checkout_cache_usage);
 		break;
@@ -155,7 +190,7 @@ int main(int argc, char **argv)
 
 		if (all)
 			die("git-checkout-index: don't mix '--all' and explicit filenames");
-		checkout_file(arg);
+		checkout_file(prefix_path(prefix, prefix_length, arg));
 	}
 
 	if (all)