GIT 1.5.0.7

Not that this release really matters, as we will be doing
1.5.1 tomorrow.  This commit is to tie the loose ends and
merge all of "maint" branch into "master" in preparation.

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

Documentation/Makefile

@@ -16,8 +16,9 @@ ARTICLES += repository-layout
 ARTICLES += hooks
 ARTICLES += everyday
 ARTICLES += git-tools
+ARTICLES += glossary
 # with their own formatting rules.
-SP_ARTICLES = glossary howto/revert-branch-rebase user-manual
+SP_ARTICLES = howto/revert-branch-rebase user-manual
 
 DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
 
@@ -106,16 +107,11 @@ user-manual.xml: user-manual.txt user-manual.conf
 	$(ASCIIDOC) -b docbook -d book $<
 
 XSLT = http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl
-XSLTOPTS = --nonet --xinclude --stringparam html.stylesheet docbook-xsl.css
+XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
 
 user-manual.html: user-manual.xml
 	xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
 
-glossary.html : glossary.txt sort_glossary.pl
-	cat $< | \
-	perl sort_glossary.pl | \
-	$(ASCIIDOC) -b xhtml11 - > glossary.html
-
 howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
 	rm -f $@+ $@
 	sh ./howto-index.sh $(wildcard howto/*.txt) >$@+

Documentation/RelNotes-1.5.0.5.txt

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

Documentation/RelNotes-1.5.0.6.txt

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

Documentation/RelNotes-1.5.0.7.txt

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

Documentation/git-am.txt

@@ -70,7 +70,7 @@ default.   You could use `--no-utf8` to override this.
 	the patch.
 
 -C<n>, -p<n>::
-	These flag are passed to the `git-apply` program that applies
+	These flags are passed to the `git-apply` program that applies
 	the patch.
 
 --interactive::

Documentation/git-rev-parse.txt

@@ -258,14 +258,14 @@ its all parents.
 
 Here are a handful examples:
 
-   D                A B D
-   D F              A B C D F
-   ^A G             B D
-   ^A F             B C F
-   G...I            C D F G I
-   ^B G I           C D F G I
-   F^@              A B C
-   F^! H            D F H
+   D                G H D
+   D F              G H I J D F
+   ^G D             H D
+   ^D B             E I J F B
+   B...C            G H D E B C
+   ^D B C           E I J F B C
+   C^@              I J F
+   F^! D            G H D F
 
 Author
 ------

Documentation/git-svnimport.txt

@@ -27,7 +27,7 @@ repository, or incrementally import into an existing one.
 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"
+"trunk" directory where the main development happens, "branches/FOO"
 directories for branches, and "/tags/FOO" directories for tags.
 Other subdirectories are ignored.
 

Documentation/glossary.txt

@@ -1,365 +1,405 @@
-alternate object database::
-	Via the alternates mechanism, a repository can inherit part of its
-	object database from another object database, which is called
-	"alternate".
+GIT Glossary
+============
 
-bare repository::
-	A bare repository is normally an appropriately named
-	directory with a `.git` suffix that does not have a
-	locally checked-out copy of any of the files under revision
-	control.  That is, all of the `git` administrative and
-	control files that would normally be present in the
-	hidden `.git` sub-directory are directly present in
-	the `repository.git` directory instead, and no other files
-	are present and checked out.  Usually publishers of public
-	repositories make bare repositories available.
+[[def_alternate_object_database]]alternate object database::
+	Via the alternates mechanism, a <<def_repository,repository>> can
+	inherit part of its <<def_object_database,object database>> from another
+	<<def_object_database,object database>>, which is called "alternate".
 
-blob object::
-	Untyped object, e.g. the contents of a file.
+[[def_bare_repository]]bare repository::
+	A <<def_bare_repository,bare repository>> is normally an appropriately
+	named <<def_directory,directory>> with a `.git` suffix that does not
+	have a locally checked-out copy of any of the files under
+	<<def_revision,revision>> control. That is, all of the `git`
+	administrative and control files that would normally be present in the
+	hidden `.git` sub-directory are directly present in the
+	`repository.git` directory instead,
+	and no other files are present and checked out. Usually publishers of
+	public repositories make bare repositories available.
 
-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/`.
+[[def_blob_object]]blob object::
+	Untyped <<def_object,object>>, e.g. the contents of a file.
 
-cache::
-	Obsolete for: index.
+[[def_branch]]branch::
+	A non-cyclical graph of revisions, i.e. the complete history of a
+	particular <<def_revision,revision>>, which is called the
+	branch <<def_head,head>>. The heads
+	are stored in `$GIT_DIR/refs/heads/`.
 
-chain::
-	A list of objects, where each object in the list contains a
-	reference to its successor (for example, the successor of a commit
-	could be one of its parents).
+[[def_cache]]cache::
+	Obsolete for: <<def_index,index>>.
 
-changeset::
-	BitKeeper/cvsps speak for "commit". Since git does not store
-	changes, but states, it really does not make sense to use
-	the term "changesets" with git.
+[[def_chain]]chain::
+	A list of objects, where each <<def_object,object>> in the list contains
+	a reference to its successor (for example, the successor of a
+	<<def_commit,commit>> could be one of its parents).
 
-checkout::
-	The action of updating the working tree to a revision which was
-	stored in the object database.
+[[def_changeset]]changeset::
+	BitKeeper/cvsps speak for "<<def_commit,commit>>". Since git does not
+	store changes, but states, it really does not make sense to use the term
+	"changesets" with git.
 
-cherry-picking::
-	In SCM jargon, "cherry pick" means to choose a subset of
-	changes out of a series of changes (typically commits)
-	and record them as a new series of changes on top of
-	different codebase.  In GIT, this is performed by
-	"git cherry-pick" command to extract the change
-	introduced by an existing commit and to record it based
-	on the tip of the current branch as a new commit.
+[[def_checkout]]checkout::
+	The action of updating the <<def_working_tree,working tree>> to a
+	<<def_revision,revision>> which was stored in the
+	<<def_object_database,object database>>.
 
-clean::
-	A working tree is clean, if it corresponds to the revision
-	referenced by the current head.  Also see "dirty".
+[[def_cherry-picking]]cherry-picking::
+	In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
+	changes out of a series of changes (typically commits) and record them
+	as a new series of changes on top of different codebase. In GIT, this is
+	performed by "git cherry-pick" command to extract the change introduced
+	by an existing <<def_commit,commit>> and to record it based on the tip
+	of the current <<def_branch,branch>> as a new <<def_commit,commit>>.
 
-commit::
-	As a verb: The action of storing the current state of the index in the
-	object database. The result is a revision.
-	As a noun: Short hand for commit object.
+[[def_clean]]clean::
+	A <<def_working_tree,working tree>> is <<def_clean,clean>>, if it
+	corresponds to the <<def_revision,revision>> referenced by the current
+	<<def_head,head>>. Also see "<<def_dirty,dirty>>".
 
-commit object::
-	An object which contains the information about a particular
-	revision, such as parents, committer, author, date and the
-	tree object which corresponds to the top directory of the
-	stored revision.
+[[def_commit]]commit::
+	As a verb: The action of storing the current state of the
+	<<def_index,index>> in the <<def_object_database,object database>>. The
+	result is a <<def_revision,revision>>. As a noun: Short hand for
+	<<def_commit_object,commit object>>.
 
-core git::
-	Fundamental data structures and utilities of git. Exposes only
-	limited source code management tools.
+[[def_commit_object]]commit object::
+	An <<def_object,object>> which contains the information about a
+	particular <<def_revision,revision>>, such as parents, committer,
+	author, date and the <<def_tree_object,tree object>> which corresponds
+	to the top <<def_directory,directory>> of the stored
+	<<def_revision,revision>>.
 
-DAG::
-	Directed acyclic graph. The commit objects form a directed acyclic
-	graph, because they have parents (directed), and the graph of commit
-	objects is acyclic (there is no chain which begins and ends with the
-	same object).
+[[def_core_git]]core git::
+	Fundamental data structures and utilities of git. Exposes only limited
+	source code management tools.
 
-dangling object::
-	An unreachable object which is not reachable even from other
-	unreachable objects; a dangling object has no references to it
-	from any reference or object in the repository.
+[[def_DAG]]DAG::
+	Directed acyclic graph. The <<def_commit,commit>> objects form a
+	directed acyclic graph, because they have parents (directed), and the
+	graph of <<def_commit,commit>> objects is acyclic (there is no
+	<<def_chain,chain>> which begins and ends with the same
+	<<def_object,object>>).
 
-dircache::
+[[def_dangling_object]]dangling object::
+	An <<def_unreachable_object,unreachable object>> which is not
+	<<def_reachable,reachable>> even from other unreachable objects; a
+	<<def_dangling_object,dangling object>> has no references to it from any
+	reference or <<def_object,object>> in the <<def_repository,repository>>.
+
+[[def_dircache]]dircache::
 	You are *waaaaay* behind.
 
-dirty::
-	A working tree is said to be dirty if it contains modifications
-	which have not been committed to the current branch.
-
-directory::
+[[def_directory]]directory::
 	The list you get with "ls" :-)
 
-ent::
-	Favorite synonym to "tree-ish" by some total geeks. See
+[[def_dirty]]dirty::
+	A <<def_working_tree,working tree>> is said to be <<def_dirty,dirty>> if
+	it contains modifications which have not been committed to the current
+	<<def_branch,branch>>.
+
+[[def_ent]]ent::
+	Favorite synonym to "<<def_tree-ish,tree-ish>>" by some total geeks. See
 	`http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
-	explanation.  Avoid this term, not to confuse people.
+	explanation. Avoid this term, not to confuse people.
 
-fast forward::
-	A fast-forward is a special type of merge where you have
-	a revision and you are "merging" another branch's changes
-	that happen to be a descendant of what you have.
-	In such these cases, you do not make a new merge commit but
-	instead just update to his revision. This will happen
-	frequently on a tracking branch of a remote repository.
+[[def_fast_forward]]fast forward::
+	A fast-forward is a special type of <<def_merge,merge>> where you have a
+	<<def_revision,revision>> and you are "merging" another
+	<<def_branch,branch>>'s changes that happen to be a descendant of what
+	you have. In such these cases, you do not make a new <<def_merge,merge>>
+	<<def_commit,commit>> but instead just update to his
+	<<def_revision,revision>>. This will happen frequently on a
+	<<def_tracking_branch,tracking branch>> of a remote
+	<<def_repository,repository>>.
 
-fetch::
-	Fetching a branch means to get the branch's head ref from a
-	remote repository, to find out which objects are missing from
-	the local object database, and to get them, too.
+[[def_fetch]]fetch::
+	Fetching a <<def_branch,branch>> means to get the
+	<<def_branch,branch>>'s <<def_head_ref,head ref>> from a remote
+	<<def_repository,repository>>, to find out which objects are missing
+	from the local <<def_object_database,object database>>, and to get them,
+	too.
 
-file system::
-	Linus Torvalds originally designed git to be a user space file
-	system, i.e. the infrastructure to hold files and directories.
-	That ensured the efficiency and speed of git.
+[[def_file_system]]file system::
+	Linus Torvalds originally designed git to be a user space file system,
+	i.e. the infrastructure to hold files and directories. That ensured the
+	efficiency and speed of git.
 
-git archive::
-	Synonym for repository (for arch people).
+[[def_git_archive]]git archive::
+	Synonym for <<def_repository,repository>> (for arch people).
 
-grafts::
-	Grafts enables two otherwise different lines of development to be
-	joined together by recording fake ancestry information for commits.
-	This way you can make git pretend the set of parents a commit
-	has is different from what was recorded when the commit was created.
-	Configured via the `.git/info/grafts` file.
+[[def_grafts]]grafts::
+	Grafts enables two otherwise different lines of development to be joined
+	together by recording fake ancestry information for commits. This way
+	you can make git pretend the set of parents a <<def_commit,commit>> has
+	is different from what was recorded when the <<def_commit,commit>> was
+	created. Configured via the `.git/info/grafts` file.
 
-hash::
-	In git's context, synonym to object name.
+[[def_hash]]hash::
+	In git's context, synonym to <<def_object_name,object name>>.
 
-head::
-	The top of a branch. It contains a ref to the corresponding
-	commit object.
+[[def_head]]head::
+	The top of a <<def_branch,branch>>. It contains a <<def_ref,ref>> to the
+	corresponding <<def_commit_object,commit object>>.
 
-head ref::
-	A ref pointing to a head. Often, this is abbreviated to "head".
-	Head refs are stored in `$GIT_DIR/refs/heads/`.
+[[def_head_ref]]head ref::
+	A <<def_ref,ref>> pointing to a <<def_head,head>>. Often, this is
+	abbreviated to "<<def_head,head>>". Head refs are stored in
+	`$GIT_DIR/refs/heads/`.
 
-hook::
-	During the normal execution of several git commands,
-	call-outs are made to optional scripts that allow
-	a developer to add functionality or checking.
-	Typically, the hooks allow for a command to be pre-verified
-	and potentially aborted, and allow for a post-notification
-	after the operation is done.
-	The hook scripts are found in the `$GIT_DIR/hooks/` directory,
-	and are enabled by simply making them executable.
+[[def_hook]]hook::
+	During the normal execution of several git commands, call-outs are made
+	to optional scripts that allow a developer to add functionality or
+	checking. Typically, the hooks allow for a command to be pre-verified
+	and potentially aborted, and allow for a post-notification after the
+	operation is done. The <<def_hook,hook>> scripts are found in the
+	`$GIT_DIR/hooks/` <<def_directory,directory>>, and are enabled by simply
+	making them executable.
 
-index::
-	A collection of files with stat information, whose contents are
-	stored as objects. The index is a stored version of your working
-	tree. Truth be told, it can also contain a second, and even a third
-	version of a working tree, which are used when merging.
+[[def_index]]index::
+	A collection of files with stat information, whose contents are stored
+	as objects. The <<def_index,index>> is a stored version of your working
+	<<def_tree,tree>>. Truth be told, it can also contain a second, and even
+	a third version of a <<def_working_tree,working tree>>, which are used
+	when merging.
 
-index entry::
-	The information regarding a particular file, stored in the index.
-	An index entry can be unmerged, if a merge was started, but not
-	yet finished (i.e. if the index contains multiple versions of
-	that file).
+[[def_index_entry]]index entry::
+	The information regarding a particular file, stored in the
+	<<def_index,index>>. An <<def_index_entry,index entry>> can be unmerged,
+	if a <<def_merge,merge>> was started, but not yet finished (i.e. if the
+	<<def_index,index>> contains multiple versions of that file).
 
-master::
-	The default development 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
+[[def_master]]master::
+	The default development <<def_branch,branch>>. Whenever you create a git
+	<<def_repository,repository>>, a <<def_branch,branch>> named
+	"<<def_master,master>>" is created, and becomes the active
+	<<def_branch,branch>>. In most cases, this contains the local
 	development, though that is purely conventional and not required.
 
-merge::
-	To merge branches means to try to accumulate the changes since a
-	common ancestor and apply them to the first branch. An automatic
-	merge uses heuristics to accomplish that. Evidently, an automatic
-	merge can fail.
+[[def_merge]]merge::
+	To <<def_merge,merge>> branches means to try to accumulate the changes
+	since a common ancestor and apply them to the first
+	<<def_branch,branch>>. An automatic <<def_merge,merge>> uses heuristics
+	to accomplish that. Evidently, an automatic <<def_merge,merge>> can
+	fail.
 
-object::
-	The unit of storage in git. It is uniquely identified by
-	the SHA1 of its contents. Consequently, an object can not
-	be changed.
+[[def_object]]object::
+	The unit of storage in git. It is uniquely identified by the
+	<<def_SHA1,SHA1>> of its contents. Consequently, an
+	<<def_object,object>> can not be changed.
 
-object database::
-	Stores a set of "objects", and an individual object is identified
-	by its object name. The objects usually live in `$GIT_DIR/objects/`.
+[[def_object_database]]object database::
+	Stores a set of "objects", and an individual <<def_object,object>> is
+	identified by its <<def_object_name,object name>>. The objects usually
+	live in `$GIT_DIR/objects/`.
 
-object identifier::
-	Synonym for object name.
+[[def_object_identifier]]object identifier::
+	Synonym for <<def_object_name,object name>>.
 
-object name::
-	The unique identifier of an object. The hash of the object's contents
-	using the Secure Hash Algorithm 1 and usually represented by the 40
-	character hexadecimal encoding of the hash of the object (possibly
-	followed by a white space).
+[[def_object_name]]object name::
+	The unique identifier of an <<def_object,object>>. The <<def_hash,hash>>
+	of the <<def_object,object>>'s contents using the Secure Hash Algorithm
+	1 and usually represented by the 40 character hexadecimal encoding of
+	the <<def_hash,hash>> of the <<def_object,object>> (possibly followed by
+	a white space).
 
-object type::
-	One of the identifiers "commit","tree","tag" and "blob" describing
-	the type of an object.
+[[def_object_type]]object type::
+	One of the identifiers
+	"<<def_commit,commit>>","<<def_tree,tree>>","<<def_tag,tag>>" or "<<def_blob_object,blob>>"
+	describing the type of an <<def_object,object>>.
 
-octopus::
-	To merge more than two branches. Also denotes an intelligent
-	predator.
+[[def_octopus]]octopus::
+	To <<def_merge,merge>> more than two branches. Also denotes an
+	intelligent predator.
 
-origin::
-	The default upstream repository. Most projects have at
-	least one upstream project which they track. By default
-	'origin' is used for that purpose.  New upstream updates
+[[def_origin]]origin::
+	The default upstream <<def_repository,repository>>. Most projects have
+	at least one upstream project which they track. By default
+	'<<def_origin,origin>>' is used for that purpose. New upstream updates
 	will be fetched into remote tracking branches named
 	origin/name-of-upstream-branch, which you can see using
-	"git branch -r".
+	"git <<def_branch,branch>> -r".
 
-pack::
-	A set of objects which have been compressed into one file (to save
-	space or to transmit them efficiently).
+[[def_pack]]pack::
+	A set of objects which have been compressed into one file (to save space
+	or to transmit them efficiently).
 
-pack index::
+[[def_pack_index]]pack index::
 	The list of identifiers, and other information, of the objects in a
-	pack, to assist in efficiently accessing the contents of a pack.
+	<<def_pack,pack>>, to assist in efficiently accessing the contents of a
+	<<def_pack,pack>>.
 
-parent::
-	A commit object contains a (possibly empty) list of the logical
-	predecessor(s) in the line of development, i.e. its parents.
+[[def_parent]]parent::
+	A <<def_commit_object,commit object>> contains a (possibly empty) list
+	of the logical predecessor(s) in the line of development, i.e. its
+	parents.
 
-pickaxe::
-	The term pickaxe refers to an option to the diffcore routines
-	that help select changes that add or delete a given text string.
-	With the --pickaxe-all option, it can be used to view the
-	full changeset that introduced or removed, say, a particular
-	line of text.  See gitlink:git-diff[1].
+[[def_pickaxe]]pickaxe::
+	The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore
+	routines that help select changes that add or delete a given text
+	string. With the --pickaxe-all option, it can be used to view the full
+	<<def_changeset,changeset>> that introduced or removed, say, a
+	particular line of text. See gitlink:git-diff[1].
 
-plumbing::
-	Cute name for core git.
+[[def_plumbing]]plumbing::
+	Cute name for <<def_core_git,core git>>.
 
-porcelain::
-	Cute name for programs and program suites depending on core git,
-	presenting a high level access to core git. Porcelains expose
-	more of a SCM interface than the plumbing.
+[[def_porcelain]]porcelain::
+	Cute name for programs and program suites depending on
+	<<def_core_git,core git>>, presenting a high level access to
+	<<def_core_git,core git>>. Porcelains expose more of a <<def_SCM,SCM>>
+	interface than the <<def_plumbing,plumbing>>.
 
-pull::
-	Pulling a branch means to fetch it and merge it.
+[[def_pull]]pull::
+	Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and
+	<<def_merge,merge>> it.
 
-push::
-	Pushing a branch means to get the branch's head ref from a remote
-	repository, find out if it is an ancestor to the branch's local
-	head ref is a direct, and in that case, putting all objects, which
-	are reachable from the local head ref, and which are missing from
-	the remote repository, into the remote object database, and updating
-	the remote head ref. If the remote head is not an ancestor to the
-	local head, the push fails.
+[[def_push]]push::
+	Pushing a <<def_branch,branch>> means to get the <<def_branch,branch>>'s
+	<<def_head_ref,head ref>> from a remote <<def_repository,repository>>,
+	find out if it is an ancestor to the <<def_branch,branch>>'s local
+	<<def_head_ref,head ref>> is a direct, and in that case, putting all
+	objects, which are <<def_reachable,reachable>> from the local
+	<<def_head_ref,head ref>>, and which are missing from the remote
+	<<def_repository,repository>>, into the remote
+	<<def_object_database,object database>>, and updating the remote
+	<<def_head_ref,head ref>>. If the remote <<def_head,head>> is not an
+	ancestor to the local <<def_head,head>>, the <<def_push,push>> fails.
 
-reachable::
-	All of the ancestors of a given commit are said to be reachable from
-	that commit.  More generally, one object is reachable from another if
-	we can reach the one from the other by a chain that follows tags to
-	whatever they tag, commits to their parents or trees, and trees to the
-	trees or blobs that they contain.
+[[def_reachable]]reachable::
+	All of the ancestors of a given <<def_commit,commit>> are said to be
+	<<def_reachable,reachable>> from that <<def_commit,commit>>. More
+	generally, one <<def_object,object>> is <<def_reachable,reachable>> from
+	another if we can reach the one from the other by a <<def_chain,chain>>
+	that follows <<def_tag,tags>> to whatever they tag,
+	<<def_commit_object,commits>> to their parents or trees, and
+	<<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>>
+	that they contain.
 
-rebase::
-	To clean a branch by starting from the head of the main line of
-	development ("master"), and reapply the (possibly cherry-picked)
-	changes from that branch.
+[[def_rebase]]rebase::
+	To reapply a series of changes from a <<def_branch,branch>> to a
+	different base, and reset the <<def_head,head>> of that branch
+	to the result.
 
-ref::
-	A 40-byte hex representation of a SHA1 or a name that denotes
-	a particular object. These may be stored in `$GIT_DIR/refs/`.
+[[def_ref]]ref::
+	A 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that
+	denotes a particular <<def_object,object>>. These may be stored in
+	`$GIT_DIR/refs/`.
 
-refspec::
-	A refspec is used by fetch and push to describe the mapping
-	between remote ref and local ref.  They are combined with
-	a colon in the format <src>:<dst>, preceded by an optional
-	plus sign, +.  For example:
-	`git fetch $URL refs/heads/master:refs/heads/origin`
-	means "grab the master branch head from the $URL and store
-	it as my origin branch head".
-	And `git push $URL refs/heads/master:refs/heads/to-upstream`
-	means "publish my master branch head as to-upstream branch
-	at $URL".   See also gitlink:git-push[1]
+[[def_refspec]]refspec::
+	A <<def_refspec,refspec>> is used by <<def_fetch,fetch>> and
+	<<def_push,push>> to describe the mapping between remote <<def_ref,ref>>
+	and local <<def_ref,ref>>. They are combined with a colon in the format
+	<src>:<dst>, preceded by an optional plus sign, +. For example: `git
+	fetch $URL refs/heads/master:refs/heads/origin` means
+	"grab the master <<def_branch,branch>> <<def_head,head>>
+	from the $URL and store it as my origin
+	<<def_branch,branch>> <<def_head,head>>". And `git <<def_push,push>>
+	$URL refs/heads/master:refs/heads/to-upstream` means
+	"publish my master <<def_branch,branch>>
+	<<def_head,head>> as to-upstream <<def_branch,branch>> at $URL". See
+	also gitlink:git-push[1]
 
-repository::
-	A collection of refs together with an object database containing
-	all objects, which are reachable from the refs, possibly accompanied
-	by meta data from one or more porcelains. A repository can
-	share an object database with other repositories.
+[[def_repository]]repository::
+	A collection of refs together with an <<def_object_database,object
+	database>> containing all objects which are <<def_reachable,reachable>>
+	from the refs, possibly accompanied by meta data from one or more
+	porcelains. A <<def_repository,repository>> can share an
+	<<def_object_database,object database>> with other repositories.
 
-resolve::
-	The action of fixing up manually what a failed automatic merge
-	left behind.
+[[def_resolve]]resolve::
+	The action of fixing up manually what a failed automatic
+	<<def_merge,merge>> left behind.
 
-revision::
-	A particular state of files and directories which was stored in
-	the object database. It is referenced by a commit object.
+[[def_revision]]revision::
+	A particular state of files and directories which was stored in the
+	<<def_object_database,object database>>. It is referenced by a
+	<<def_commit_object,commit object>>.
 
-rewind::
-	To throw away part of the development, i.e. to assign the head to
-	an earlier revision.
+[[def_rewind]]rewind::
+	To throw away part of the development, i.e. to assign the
+	<<def_head,head>> to an earlier <<def_revision,revision>>.
 
-SCM::
+[[def_SCM]]SCM::
 	Source code management (tool).
 
-SHA1::
-	Synonym for object name.
+[[def_SHA1]]SHA1::
+	Synonym for <<def_object_name,object name>>.
 
-shallow repository::
-	A shallow repository has an incomplete history some of
-	whose commits have parents cauterized away (in other
-	words, git is told to pretend that these commits do not
-	have the parents, even though they are recorded in the
-	commit object).  This is sometimes useful when you are
-	interested only in the recent history of a project even
-	though the real history recorded in the upstream is
-	much larger.  A shallow repository is created by giving
-	`--depth` option to gitlink:git-clone[1], and its
-	history can be later deepened with gitlink:git-fetch[1].
+[[def_shallow_repository]]shallow repository::
+	A <<def_shallow_repository,shallow repository>> has an incomplete
+	history some of whose commits have parents cauterized away (in other
+	words, git is told to pretend that these commits do not have the
+	parents, even though they are recorded in the <<def_commit_object,commit
+	object>>). This is sometimes useful when you are interested only in the
+	recent history of a project even though the real history recorded in the
+	upstream is much larger. A <<def_shallow_repository,shallow repository>>
+	is created by giving the `--depth` option to gitlink:git-clone[1], and
+	its history can be later deepened with gitlink:git-fetch[1].
 
-symref::
-	Symbolic reference: instead of containing the SHA1 id itself, it
-	is of the format 'ref: refs/some/thing' and when referenced, it
-	recursively dereferences to this reference. 'HEAD' is a prime
-	example of a symref. Symbolic references are manipulated with
-	the gitlink:git-symbolic-ref[1] command.
+[[def_symref]]symref::
+	Symbolic reference: instead of containing the <<def_SHA1,SHA1>> id
+	itself, it is of the format 'ref: refs/some/thing' and when
+	referenced, it recursively dereferences to this reference. 'HEAD' is a
+	prime example of a <<def_symref,symref>>. Symbolic references are
+	manipulated with the gitlink:git-symbolic-ref[1] command.
 
-topic branch::
-	A regular git branch that is used by a developer to
-	identify a conceptual line of development.  Since branches
-	are very easy and inexpensive, it is often desirable to
-	have several small branches that each contain very well
-	defined concepts or small incremental yet related changes.
+[[def_tag]]tag::
+	A <<def_ref,ref>> pointing to a <<def_tag,tag>> or
+	<<def_commit_object,commit object>>. In contrast to a <<def_head,head>>,
+	a tag is not changed by a <<def_commit,commit>>. Tags (not
+	<<def_tag_object,tag objects>>) are stored in `$GIT_DIR/refs/tags/`. A
+	git tag has nothing to do with a Lisp tag (which would be
+	called an <<def_object_type,object type>> in git's context). A
+	tag is most typically used to mark a particular point in the
+	<<def_commit,commit>> ancestry <<def_chain,chain>>.
 
-tracking branch::
-	A regular git branch that is used to follow changes from
-	another repository.  A tracking branch should not contain
-	direct modifications or have local commits made to it.
-	A tracking branch can usually be identified as the
-	right-hand-side ref in a Pull: refspec.
+[[def_tag_object]]tag object::
+	An <<def_object,object>> containing a <<def_ref,ref>> pointing to
+	another <<def_object,object>>, which can contain a message just like a
+	<<def_commit_object,commit object>>. It can also contain a (PGP)
+	signature, in which case it is called a "signed <<def_tag_object,tag
+	object>>".
 
-tree object::
-	An object containing a list of file names and modes along with refs
-	to the associated blob and/or tree objects. A tree is equivalent
-	to a directory.
+[[def_topic_branch]]topic branch::
+	A regular git <<def_branch,branch>> that is used by a developer to
+	identify a conceptual line of development. Since branches are very easy
+	and inexpensive, it is often desirable to have several small branches
+	that each contain very well defined concepts or small incremental yet
+	related changes.
 
-tree::
-	Either a working tree, or a tree object together with the
-	dependent blob and tree objects (i.e. a stored representation
-	of a working tree).
+[[def_tracking_branch]]tracking branch::
+	A regular git <<def_branch,branch>> that is used to follow changes from
+	another <<def_repository,repository>>. A <<def_tracking_branch,tracking
+	branch>> should not contain direct modifications or have local commits
+	made to it. A <<def_tracking_branch,tracking branch>> can usually be
+	identified as the right-hand-side <<def_ref,ref>> in a Pull:
+	<<def_refspec,refspec>>.
 
-tree-ish::
-	A ref pointing to either a commit object, a tree object, or a
-	tag object pointing to a tag or commit or tree object.
+[[def_tree]]tree::
+	Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree
+	object>> together with the dependent blob and <<def_tree,tree>> objects
+	(i.e. a stored representation of a <<def_working_tree,working tree>>).
 
-tag object::
-	An object containing a ref pointing to another object, which can
-	contain a message just like a commit object. It can also
-	contain a (PGP) signature, in which case it is called a "signed
-	tag object".
+[[def_tree_object]]tree object::
+	An <<def_object,object>> containing a list of file names and modes along
+	with refs to the associated blob and/or tree objects. A
+	<<def_tree,tree>> is equivalent to a <<def_directory,directory>>.
 
-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
-	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.
+[[def_tree-ish]]tree-ish::
+	A <<def_ref,ref>> pointing to either a <<def_commit_object,commit
+	object>>, a <<def_tree_object,tree object>>, or a <<def_tag_object,tag
+	object>> pointing to a <<def_tag,tag>> or <<def_commit,commit>> or
+	<<def_tree_object,tree object>>.
 
-unmerged index::
-	An index which contains unmerged index entries.
+[[def_unmerged_index]]unmerged index::
+	An <<def_index,index>> which contains unmerged
+	<<def_index_entry,index entries>>.
 
-unreachable object::
-	An object which is not reachable from a branch, tag, or any
-	other reference.
-
-working tree::
-	The set of files and directories currently being worked on,
-	i.e. you can work in your working tree without using git at all.
+[[def_unreachable_object]]unreachable object::
+	An <<def_object,object>> which is not <<def_reachable,reachable>> from a
+	<<def_branch,branch>>, <<def_tag,tag>>, or any other reference.
 
+[[def_working_tree]]working tree::
+	The set of files and directories currently being worked on, i.e. you can
+	work in your <<def_working_tree,working tree>> without using git at all.

Documentation/sort_glossary.pl

@@ -1,69 +0,0 @@
-#!/usr/bin/perl
-
-%terms=();
-
-while(<>) {
-	if(/^(\S.*)::$/) {
-		my $term=$1;
-		if(defined($terms{$term})) {
-			die "$1 defined twice\n";
-		}
-		$terms{$term}="";
-		LOOP: while(<>) {
-			if(/^$/) {
-				last LOOP;
-			}
-			if(/^	\S/) {
-				$terms{$term}.=$_;
-			} else {
-				die "Error 1: $_";
-			}
-		}
-	}
-}
-
-sub format_tab_80 ($) {
-	my $text=$_[0];
-	my $result="";
-	$text=~s/\s+/ /g;
-	$text=~s/^\s+//;
-	while($text=~/^(.{1,72})(|\s+(\S.*)?)$/) {
-		$result.="	".$1."\n";
-		$text=$3;
-	}
-	return $result;
-}
-
-sub no_spaces ($) {
-	my $result=$_[0];
-	$result=~tr/ /_/;
-	return $result;
-}
-
-print 'GIT Glossary
-============
-
-This list is sorted alphabetically:
-
-';
-
-@keys=sort {uc($a) cmp uc($b)} keys %terms;
-$pattern='(\b(?<!link:git-)'.join('\b|\b(?<!-)',reverse @keys).'\b)';
-foreach $key (@keys) {
-	$terms{$key}=~s/$pattern/sprintf "<<ref_".no_spaces($1).",$1>>";/eg;
-	print '[[ref_'.no_spaces($key).']]'.$key."::\n"
-		.format_tab_80($terms{$key})."\n";
-}
-
-print '
-
-Author
-------
-Written by Johannes Schindelin <Johannes.Schindelin@gmx.de> and
-the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the link:git.html[git] suite
-';
-

Documentation/technical/pack-format.txt

@@ -21,11 +21,11 @@ GIT pack format
      which looks like this:
 
      (undeltified representation)
-     n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+     n-byte type and length (3-bit type, (n-1)*7+4-bit length)
      compressed data
 
      (deltified representation)
-     n-byte type and length (4-bit type, (n-1)*7+4-bit length)
+     n-byte type and length (3-bit type, (n-1)*7+4-bit length)
      20-byte base object name
      compressed delta data
 
@@ -102,11 +102,13 @@ trailer	  | | packfile checksum              |
 Pack file entry: <+
 
      packed object header:
-	1-byte type (upper 4-bit)
+	1-byte size extension bit (MSB)
+	       type (next 3 bit)
 	       size0 (lower 4-bit) 
         n-byte sizeN (as long as MSB is set, each 7-bit)
 		size0..sizeN form 4+7+7+..+7 bit integer, size0
-		is the most significant part.
+		is the least significant part, and sizeN is the
+		most significant part.
      packed object data:
         If it is not DELTA, then deflated bytes (the size above
 		is the size before compression).

Documentation/user-manual.txt

@@ -288,21 +288,22 @@ collection of files.  It stores the history as a compressed
 collection of interrelated snapshots (versions) of the project's
 contents.
 
-A single git repository may contain multiple branches.  Each branch
-is a bookmark referencing a particular point in the project history.
-The gitlink:git-branch[1] command shows you the list of branches:
+A single git repository may contain multiple branches.  It keeps track
+of them by keeping a list of <<def_head,heads>> which reference the
+latest version on each branch; the gitlink:git-branch[1] command shows
+you the list of branch heads:
 
 ------------------------------------------------
 $ git branch
 * master
 ------------------------------------------------
 
-A freshly cloned repository contains a single branch, named "master",
-and the working directory contains the version of the project
-referred to by the master branch.
+A freshly cloned repository contains a single branch head, named
+"master", and working directory is initialized to the state of
+the project referred to by "master".
 
-Most projects also use tags.  Tags, like branches, are references
-into the project's history, and can be listed using the
+Most projects also use <<def_tag,tags>>.  Tags, like heads, are
+references into the project's history, and can be listed using the
 gitlink:git-tag[1] command:
 
 ------------------------------------------------
@@ -320,9 +321,9 @@ v2.6.13
 ------------------------------------------------
 
 Tags are expected to always point at the same version of a project,
-while branches are expected to advance as development progresses.
+while heads are expected to advance as development progresses.
 
-Create a new branch pointing to one of these versions and check it
+Create a new branch head pointing to one of these versions and check it
 out using gitlink:git-checkout[1]:
 
 ------------------------------------------------
@@ -346,10 +347,10 @@ the current branch to point at v2.6.17 instead, with
 $ git reset --hard v2.6.17
 ------------------------------------------------
 
-Note that if the current branch was your only reference to a
+Note that if the current branch head was your only reference to a
 particular point in history, then resetting that branch may leave you
-with no way to find the history it used to point to; so use this
-command carefully.
+with no way to find the history it used to point to; so use this command
+carefully.
 
 Understanding History: Commits
 ------------------------------
@@ -452,17 +453,15 @@ be replaced with another letter or number.
 Understanding history: What is a branch?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Though we've been using the word "branch" to mean a kind of reference
-to a particular commit, the word branch is also commonly used to
-refer to the line of commits leading up to that point.  In the
-example above, git may think of the branch named "A" as just a
-pointer to one particular commit, but we may refer informally to the
-line of three commits leading up to that point as all being part of
+When we need to be precise, we will use the word "branch" to mean a line
+of development, and "branch head" (or just "head") to mean a reference
+to the most recent commit on a branch.  In the example above, the branch
+head named "A" is a pointer to one particular commit, but we refer to
+the line of three commits leading up to that point as all being part of
 "branch A".
 
-If we need to make it clear that we're just talking about the most
-recent commit on the branch, we may refer to that commit as the
-"head" of the branch.
+However, when no confusion will result, we often just use the term
+"branch" both for branches and for branch heads.
 
 Manipulating branches
 ---------------------
@@ -1698,7 +1697,7 @@ If you and maintainer both have accounts on the same machine, then
 then you can just pull changes from each other's repositories
 directly; note that all of the commands (gitlink:git-clone[1],
 git-fetch[1], git-pull[1], etc.) that accept a URL as an argument
-will also accept a local file patch; so, for example, you can
+will also accept a local directory name; so, for example, you can
 use
 
 -------------------------------------------------
@@ -3013,9 +3012,6 @@ confusing and scary messages, but it won't actually do anything bad. In
 contrast, running "git prune" while somebody is actively changing the 
 repository is a *BAD* idea).
 
-Glossary of git terms
-=====================
-
 include::glossary.txt[]
 
 Notes and todo list for this manual

GIT-VERSION-GEN

@@ -1,7 +1,7 @@
 #!/bin/sh
 
 GVF=GIT-VERSION-FILE
-DEF_VER=v1.5.0.4.GIT
+DEF_VER=v1.5.0.7.GIT
 
 LF='
 '

RelNotes

@@ -1 +1 @@
-Documentation/RelNotes-1.5.0.4.txt
+Documentation/RelNotes-1.5.0.7.txt

builtin-rerere.c

@@ -78,6 +78,13 @@ static void append_line(struct buffer *buffer, const char *line)
 	buffer->nr += len;
 }
 
+static void clear_buffer(struct buffer *buffer)
+{
+	free(buffer->ptr);
+	buffer->ptr = NULL;
+	buffer->nr = buffer->alloc = 0;
+}
+
 static int handle_file(const char *path,
 	 unsigned char *sha1, const char *output)
 {
@@ -131,6 +138,8 @@ static int handle_file(const char *path,
 				SHA1_Update(&ctx, two->ptr, two->nr);
 				SHA1_Update(&ctx, "\0", 1);
 			}
+			clear_buffer(one);
+			clear_buffer(two);
 		} else if (hunk == 1)
 			append_line(one, buf);
 		else if (hunk == 2)

commit.c

@@ -644,6 +644,7 @@ static char *get_header(const struct commit *commit, const char *key)
 static char *replace_encoding_header(char *buf, char *encoding)
 {
 	char *encoding_header = strstr(buf, "\nencoding ");
+	char *header_end = strstr(buf, "\n\n");
 	char *end_of_encoding_header;
 	int encoding_header_pos;
 	int encoding_header_len;
@@ -651,8 +652,10 @@ static char *replace_encoding_header(char *buf, char *encoding)
 	int need_len;
 	int buflen = strlen(buf) + 1;
 
-	if (!encoding_header)
-		return buf; /* should not happen but be defensive */
+	if (!header_end)
+		header_end = buf + buflen;
+	if (!encoding_header || encoding_header >= header_end)
+		return buf;
 	encoding_header++;
 	end_of_encoding_header = strchr(encoding_header, '\n');
 	if (!end_of_encoding_header)

git-commit.sh

@@ -360,7 +360,7 @@ t,)
 		if test -z "$initial_commit"
 		then
 			cp "$THIS_INDEX" "$TMP_INDEX"
-			GIT_INDEX_FILE="$TMP_INDEX" git-read-tree -m HEAD
+			GIT_INDEX_FILE="$TMP_INDEX" git-read-tree -i -m HEAD
 		else
 			rm -f "$TMP_INDEX"
 		fi || exit

git-merge.sh

@@ -292,13 +292,13 @@ f,*)
 	# Again the most common case of merging one remote.
 	echo "Updating $(git-rev-parse --short $head)..$(git-rev-parse --short $1)"
 	git-update-index --refresh 2>/dev/null
-	new_head=$(git-rev-parse --verify "$1^0") &&
-	git-read-tree -v -m -u --exclude-per-directory=.gitignore $head "$new_head" &&
 	msg="Fast forward"
 	if test -n "$have_message"
 	then
 		msg="$msg (no commit created; -m option ignored)"
 	fi
+	new_head=$(git-rev-parse --verify "$1^0") &&
+	git-read-tree -v -m -u --exclude-per-directory=.gitignore $head "$new_head" &&
 	finish "$new_head" "$msg" || exit
 	dropsave
 	exit 0

gitweb/INSTALL

@@ -0,0 +1,184 @@
+GIT web Interface (gitweb) Installation
+=======================================
+
+First you have to generate gitweb.cgi from gitweb.perl using
+"make gitweb/gitweb.cgi", then copy appropriate files (gitweb.cgi,
+gitweb.css, git-logo.png and git-favicon.png) to their destination.
+For example if git was (or is) installed with /usr prefix, you can do
+
+	$ make prefix=/usr gitweb/gitweb.cgi  ;# as yourself
+	# cp gitweb/git* /var/www/cgi-bin/    ;# as root
+
+Alternatively you can use autoconf generated ./configure script to
+set up path to git binaries (via config.mak.autogen), so you can write
+instead
+
+	$ make configure                     ;# as yourself
+	$ ./configure --prefix=/usr          ;# as yourself
+	$ make gitweb/gitweb.cgi             ;# as yourself
+	# cp gitweb/git* /var/www/cgi-bin/   ;# as root
+
+The above example assumes that your web server is configured to run
+[executable] files in /var/www/cgi-bin/ as server scripts (as CGI
+scripts).
+
+
+Build time configuration
+------------------------
+
+See also "How to configure gitweb for your local system" in README
+file for gitweb (in gitweb/README).
+
+- There are many configuration variables which affects building of
+  gitweb.cgi; see "default configuration for gitweb" section in main
+  (top dir) Makefile, and instructions for building gitweb/gitweb.cgi
+  target.
+
+  One of most important is where to find git wrapper binary. Gitweb
+  tries to find git wrapper at $(bindir)/git, so you have to set $bindir
+  when building gitweb.cgi, or $prefix from which $bindir is derived. If
+  you build and install gitweb together with the rest of git suite,
+  there should be no problems. Otherwise, if git was for example
+  installed from a binary package, you have to set $prefix (or $bindir)
+  accordingly.
+
+- Another important issue is where are git repositories you want to make
+  available to gitweb. By default gitweb search for repositories under
+  /pub/git; if you want to have projects somewhere else, like /home/git,
+  use GITWEB_PROJECTROOT build configuration variable.
+
+  By default all git repositories under projectroot are visible and
+  available to gitweb. List of projects is generated by default by
+  scanning the projectroot directory for git repositories. This can be
+  changed (configured) as described in "Gitweb repositories" section
+  below.
+
+  Note that gitweb deals directly with object database, and does not
+  need working directory; the name of the project is the name of its
+  repository object database, usually projectname.git for bare
+  repositories. If you want to provide gitweb access to non-bare (live)
+  repository, you can make projectname.git symbolic link under
+  projectroot linking to projectname/.git (but it is just
+  a suggestion).
+
+- You can control where gitweb tries to find its main CSS style file,
+  its favicon and logo with GITWEB_CSS, GITWEB_FAVICON and GITWEB_LOGO
+  build configuration variables. By default gitweb tries to find them
+  in the same directory as gitweb.cgi script.
+
+Build example
+~~~~~~~~~~~~~
+
+- To install gitweb to /var/www/cgi-bin/gitweb/ when git wrapper
+  is installed at /usr/local/bin/git and the repositories (projects)
+  we want to display are under /home/local/scm, you can do
+
+	make GITWEB_PROJECTROOT="/home/local/scm" \
+	     GITWEB_CSS="/gitweb/gitweb.css" \
+	     GITWEB_LOGO="/gitweb/git-logo.png" \
+	     GITWEB_FAVICON="/gitweb/git-favicon.png" \
+	     bindir=/usr/local/bin \
+	     gitweb/gitweb.cgi
+
+	cp -fv ~/git/gitweb/gitweb.{cgi,css} \
+	       ~/git/gitweb/git-{favicon,logo}.png \
+	     /var/www/cgi-bin/gitweb/
+
+
+Gitweb config file
+------------------
+
+See also "Runtime gitweb configuration" section in README file
+for gitweb (in gitweb/README).
+
+- You can configure gitweb further using gitweb configuration file;
+  by default it is file named gitweb_config.perl in the same place as
+  gitweb.cgi script. You can control default place for config file
+  using GITWEB_CONFIG build configuration variable, and you can set it
+  using GITWEB_CONFIG environmental variable.
+
+- Gitweb config file is [fragment] of perl code. You can set variables
+  using "our $variable = value"; text from "#" character until the end
+  of a line is ignored. See perlsyn(1) for details.
+
+  See the top of gitweb.perl file for examples of customizable options.
+
+
+Gitweb repositories:
+--------------------
+
+- By default all git repositories under projectroot are visible and
+  available to gitweb. List of projects is generated by default by
+  scanning the projectroot directory for git repositories (for object
+  databases to be more exact).
+
+  You can provide pre-generated list of [visible] repositories,
+  together with information about their owners (the project ownership
+  is taken from owner of repository directory otherwise), by setting
+  GITWEB_LIST build configuration variable (or $projects_list variable
+  in gitweb config file) to point to a plain file.
+
+  Each line of projects list file should consist of url-encoded path
+  to project repository database (relative to projectroot) separated
+  by space from url-encoded project owner; spaces in both project path
+  and project owner have to be encoded as either '%20' or '+'.
+
+  You can generate projects list index file using project_index action
+  (the 'TXT' link on projects list page) directly from gitweb.
+
+- By default even if project is not visible on projects list page, you
+  can view it nevertheless by hand-crafting gitweb URL. You can set
+  GITWEB_STRICT_EXPORT build configuration variable (or $strict_export
+  variable in gitweb config file) to only allow viewing of
+  repositories also shown on the overview page.
+
+- Alternatively, you can configure gitweb to only list and allow
+  viewing of the explicitly exported repositories, via
+  GITWEB_EXPORT_OK build configuration variable (or $export_ok
+  variable in gitweb config file). If it evaluates to true, gitweb
+  show repository only if this file exists in its object database
+  (if directory has the magic file $export_ok).
+
+
+Requirements
+------------
+
+ - Core git tools
+ - Perl
+ - Perl modules: CGI, Encode, Fcntl, File::Find, File::Basename.
+ - web server
+
+
+Example web server configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+See also "Webserver configuration" section in README file for gitweb
+(in gitweb/README).
+
+
+- Apache2, gitweb installed as CGI script,
+  under /var/www/cgi-bin/
+
+	ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
+
+	<Directory "/var/www/cgi-bin">
+	    Options Indexes FollowSymlinks ExecCGI
+	    AllowOverride None
+	    Order allow,deny
+	    Allow from all
+	</Directory>
+
+- Apache2, gitweb installed as mod_perl legacy script,
+  under /var/www/perl/
+
+	Alias /perl "/var/www/perl"
+
+	<Directory "/var/www/perl">
+	    SetHandler perl-script
+	    PerlResponseHandler ModPerl::Registry
+	    PerlOptions +ParseHeaders
+	    Options Indexes FollowSymlinks +ExecCGI
+	    AllowOverride None
+	    Order allow,deny
+	    Allow from all
+	</Directory>

gitweb/gitweb.css

@@ -107,7 +107,7 @@ span.age {
 	font-style: italic;
 }
 
-div.page_body span.signoff {
+span.signoff {
 	color: #888888;
 }
 

gitweb/gitweb.perl

@@ -591,7 +591,7 @@ sub esc_html ($;%) {
 	my %opts = @_;
 
 	$str = to_utf8($str);
-	$str = escapeHTML($str);
+	$str = $cgi->escapeHTML($str);
 	if ($opts{'-nbsp'}) {
 		$str =~ s/ / /g;
 	}
@@ -605,7 +605,7 @@ sub esc_path {
 	my %opts = @_;
 
 	$str = to_utf8($str);
-	$str = escapeHTML($str);
+	$str = $cgi->escapeHTML($str);
 	if ($opts{'-nbsp'}) {
 		$str =~ s/ / /g;
 	}
@@ -1974,17 +1974,17 @@ sub git_print_page_path {
 			$fullname .= ($fullname ? '/' : '') . $dir;
 			print $cgi->a({-href => href(action=>"tree", file_name=>$fullname,
 			                             hash_base=>$hb),
-			              -title => esc_html($fullname)}, esc_path($dir));
+			              -title => $fullname}, esc_path($dir));
 			print " / ";
 		}
 		if (defined $type && $type eq 'blob') {
 			print $cgi->a({-href => href(action=>"blob_plain", file_name=>$file_name,
 			                             hash_base=>$hb),
-			              -title => esc_html($name)}, esc_path($basename));
+			              -title => $name}, esc_path($basename));
 		} elsif (defined $type && $type eq 'tree') {
 			print $cgi->a({-href => href(action=>"tree", file_name=>$file_name,
 			                             hash_base=>$hb),
-			              -title => esc_html($name)}, esc_path($basename));
+			              -title => $name}, esc_path($basename));
 			print " / ";
 		} else {
 			print esc_path($basename);
@@ -3719,7 +3719,7 @@ sub git_commit {
 		$formats_nav .=
 			'(merge: ' .
 			join(' ', map {
-				$cgi->a({-href => href(action=>"commitdiff",
+				$cgi->a({-href => href(action=>"commit",
 				                       hash=>$_)},
 				        esc_html(substr($_, 0, 7)));
 			} @$parents ) .

t/t4118-apply-empty-context.sh

@@ -23,7 +23,8 @@ test_expect_success setup '
 	cat file2 >file2.orig
 	git add file1 file2 &&
 	sed -e "/^B/d" <file1.orig >file1 &&
-	sed -e "/^B/d" <file2.orig >file2 &&
+	sed -e "/^[BQ]/d" <file2.orig >file2 &&
+	echo Q | tr -d "\\012" >>file2 &&
 	cat file1 >file1.mods &&
 	cat file2 >file2.mods &&
 	git diff |

t/t4200-rerere.sh

@@ -34,7 +34,8 @@ EOF
 git commit -q -a -m first
 
 git checkout -b second master
-git show first:a1 | sed 's/To die, t/To die! T/' > a1
+git show first:a1 |
+sed -e 's/To die, t/To die! T/' -e 's/life;$/life./' > a1
 git commit -q -a -m second
 
 # activate rerere
@@ -42,19 +43,26 @@ mkdir .git/rr-cache
 
 test_expect_failure 'conflicting merge' 'git pull . first'
 
-sha1=4f58849a60b4f969a2848966b6d02893b783e8fb
+sha1=$(sed -e 's/\t.*//' .git/rr-cache/MERGE_RR)
 rr=.git/rr-cache/$sha1
 test_expect_success 'recorded preimage' "grep ======= $rr/preimage"
 
 test_expect_success 'no postimage or thisimage yet' \
 	"test ! -f $rr/postimage -a ! -f $rr/thisimage"
 
+test_expect_success 'preimage have right number of lines' '
+
+	cnt=$(sed -ne "/^<<<<<<</,/^>>>>>>>/p" $rr/preimage | wc -l) &&
+	test "$cnt" = 10
+
+'
+
 git show first:a1 > a1
 
 cat > expect << EOF
 --- a/a1
 +++ b/a1
-@@ -6,11 +6,7 @@
+@@ -6,17 +6,9 @@
  The heart-ache and the thousand natural shocks
  That flesh is heir to, 'tis a consummation
  Devoutly to be wish'd.
@@ -66,8 +74,13 @@ cat > expect << EOF
  To sleep: perchance to dream: ay, there's the rub;
  For in that sleep of death what dreams may come
  When we have shuffled off this mortal coil,
+ Must give us pause: there's the respect
+-<<<<<<<
+-That makes calamity of so long life.
+-=======
+ That makes calamity of so long life;
+->>>>>>>
 EOF
-
 git rerere diff > out
 
 test_expect_success 'rerere diff' 'diff -u expect out'

upload-pack.c

@@ -119,6 +119,7 @@ static void create_pack_file(void)
 		int i;
 		struct rev_info revs;
 
+		close(lp_pipe[0]);
 		pack_pipe = fdopen(lp_pipe[1], "w");
 
 		if (create_full_pack)