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