GIT 0.99.9e

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

Documentation/git-clone.txt

@@ -12,7 +12,22 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-Clones a repository into a newly created directory.
+Clones a repository into a newly created directory.  All remote
+branch heads are copied under `$GIT_DIR/refs/heads/`, except
+that the remote `master` is also copied to `origin` branch.
+
+In addition, `$GIT_DIR/remotes/origin` file is set up to have
+this line:
+
+	Pull: master:origin
+
+This is to help the typical workflow of working off of the
+remote `master` branch.  Every time `git pull` without argument
+is run, the progress on the remote `master` branch is tracked by
+copying it into the local `origin` branch, and merged into the
+branch you are currently working on.  Remote branches other than
+`master` are also added there to be tracked.
+
 
 OPTIONS
 -------
@@ -28,9 +43,10 @@ OPTIONS
 --shared::
 -s::
 	When the repository to clone is on the local machine,
-	instead of using hard links automatically setup
+	instead of using hard links, automatically setup
 	.git/objects/info/alternatives to share the objects
-	with the source repository
+	with the source repository.  The resulting repository
+	starts out without any object of its own.
 
 --quiet::
 -q::
@@ -49,14 +65,13 @@ OPTIONS
 
 <repository>::
 	The (possibly remote) repository to clone from.  It can
-	be an "rsync://host/dir" URL, an "http://host/dir" URL,
-	or [<host>:]/dir notation that is used by 'git-clone-pack'.
-	Currently http transport is not supported.
+	be any URL git-fetch supports.
 
 <directory>::
 	The name of a new directory to be cloned into.  It is an
 	error to specify an existing directory.
 
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>

Documentation/git-http-push.txt

@@ -0,0 +1,89 @@
+git-http-push(1)
+================
+
+NAME
+----
+git-http-push - Push missing objects using HTTP/DAV.
+
+
+SYNOPSIS
+--------
+'git-http-push' [--complete] [--force] [--verbose] <url> <ref> [<ref>...]
+
+DESCRIPTION
+-----------
+Sends missing objects to remote repository, and updates the
+remote branch.
+
+
+OPTIONS
+-------
+--complete::
+	Do not assume that the remote repository is complete in its
+	current state, and verify all objects in the entire local
+	ref's history exist in the remote repository.
+
+--force::
+	Usually, the command refuses to update a remote ref that
+	is not an ancestor of the local ref used to overwrite it.
+	This flag disables the check.  What this means is that
+	the remote repository can lose commits; use it with
+	care.
+
+--verbose::
+	Report the list of objects being walked locally and the
+	list of objects successfully sent to the remote repository.
+
+<ref>...:
+	The remote refs to update.
+
+
+Specifying the Refs
+-------------------
+
+A '<ref>' specification can be either a single pattern, or a pair
+of such patterns separated by a colon ":" (this means that a ref name
+cannot have a colon in it).  A single pattern '<name>' is just a 
+shorthand for '<name>:<name>'.
+
+Each pattern pair consists of the source side (before the colon)
+and the destination side (after the colon).  The ref to be
+pushed is determined by finding a match that matches the source
+side, and where it is pushed is determined by using the
+destination side.
+
+ - It is an error if <src> does not match exactly one of the
+   local refs.
+
+ - If <dst> does not match any remote ref, either
+
+   * it has to start with "refs/"; <dst> is used as the
+     destination literally in this case.
+
+   * <src> == <dst> and the ref that matched the <src> must not
+     exist in the set of remote refs; the ref matched <src>
+     locally is used as the name of the destination.
+
+Without '--force', the <src> ref is stored at the remote only if
+<dst> does not exist, or <dst> is a proper subset (i.e. an
+ancestor) of <src>.  This check, known as "fast forward check",
+is performed in order to avoid accidentally overwriting the
+remote ref and lose other peoples' commits from there.
+
+With '--force', the fast forward check is disabled for all refs.
+
+Optionally, a <ref> parameter can be prefixed with a plus '+' sign
+to disable the fast-forward check only on that ref.
+
+
+Author
+------
+Written by Nick Hengeveld <nickh@reactrix.com>
+
+Documentation
+--------------
+Documentation by Nick Hengeveld
+
+GIT
+---
+Part of the gitlink:git[7] suite

Documentation/git-merge.txt

@@ -34,6 +34,8 @@ include::merge-pull-opts.txt[]
 	least one <remote>.  Specifying more than one <remote>
 	obviously means you are trying an Octopus.
 
+include::merge-strategies.txt[]
+
 
 SEE ALSO
 --------

Documentation/git-pull.txt

@@ -31,42 +31,8 @@ include::pull-fetch-param.txt[]
 
 include::merge-pull-opts.txt[]
 
+include::merge-strategies.txt[]
 
-MERGE STRATEGIES
-----------------
-
-resolve::
-	This can only resolve two heads (i.e. the current branch
-	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.
-
-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
-	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.
-
-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.
-
-ours::
-	This resolves any number of heads, but the result of the
-	merge is always the current branch head.  It is meant to
-	be used to supersede old development history of side
-	branches.
 
 
 EXAMPLES

Documentation/install-webdoc.sh

@@ -2,7 +2,7 @@
 
 T="$1"
 
-for h in *.html howto/*.txt howto/*.html
+for h in *.html *.txt howto/*.txt howto/*.html
 do
 	diff -u -I'Last updated [0-9][0-9]-[A-Z][a-z][a-z]-' "$T/$h" "$h" || {
 		echo >&2 "# install $h $T/$h"
@@ -12,7 +12,7 @@ do
 	}
 done
 strip_leading=`echo "$T/" | sed -e 's|.|.|g'`
-for th in "$T"/*.html "$T"/howto/*.txt "$T"/howto/*.html
+for th in "$T"/*.html "$T"/*.txt "$T"/howto/*.txt "$T"/howto/*.html
 do
 	h=`expr "$th" : "$strip_leading"'\(.*\)'`
 	case "$h" in

Documentation/merge-strategies.txt

@@ -0,0 +1,35 @@
+MERGE STRATEGIES
+----------------
+
+resolve::
+	This can only resolve two heads (i.e. the current branch
+	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.
+
+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
+	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.
+
+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.
+
+ours::
+	This resolves any number of heads, but the result of the
+	merge is always the current branch head.  It is meant to
+	be used to supersede old development history of side
+	branches.

Documentation/pull-fetch-param.txt

@@ -82,14 +82,19 @@ must know this is the expected usage pattern for a branch.
 [NOTE]
 You never do your own development on branches that appear
 on the right hand side of a <refspec> colon on `Pull:` lines;
-they are to be updated by `git-fetch`.  The corollary is that
-a local branch should be introduced and named on a <refspec>
-right-hand-side if you intend to do development derived from
-that branch.
-This leads to the common `Pull: master:origin` mapping of a
-remote `master` branch to a local `origin` branch, which
-is then merged to a local development branch, again typically
-named `master`.
+they are to be updated by `git-fetch`.  If you intend to do
+development derived from a remote branch `B`, have a `Pull:`
+line to track it (i.e. `Pull: B:remote-B`), and have a separate
+branch `my-B` to do your development on top of it.  The latter
+is created by `git branch my-B remote-B` (or its equivalent `git
+checkout -b my-B remote-B`).  Run `git fetch` to keep track of
+the progress of the remote side, and when you see something new
+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
+when you run `git clone` for you to follow this pattern.
 +
 [NOTE]
 There is a difference between listing multiple <refspec>

INSTALL

@@ -46,6 +46,9 @@ Issues of note:
 	  transfer, you are probabaly OK if you do not have
 	  them.
 
+	- expat library; git-http-push uses it for remote lock
+	  management over DAV.  Similar to "curl" above, this is optional.
+
 	- "GNU diff" to generate patches.  Of course, you don't _have_ to
 	  generate patches if you don't want to, but let's face it, you'll
 	  be wanting to. Or why did you get git in the first place?