GIT 1.5.0.6

The function replace_encoding_header is given the whole
commit buffer, including the commit message. When looking
for the encoding header, if none was found in the header, it
would locate any line in the commit message matching
"\nencoding " and remove it.

Instead, we now make sure to search only to the end of the
header.

Signed-off-by: Jeff King <peff@peff.net>
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.4.txt

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

Documentation/RelNotes-1.5.0.5.txt

@@ -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/SubmittingPatches

@@ -1,3 +1,30 @@
+Checklist (and a short version for the impatient):
+
+	- make commits of logical units
+	- check for unnecessary whitespace with "git diff --check"
+	  before committing
+	- do not check in commented out code or unneeded files
+	- provide a meaningful commit message
+	- the first line of the commit message should be a short
+	  description and should skip the full stop
+	- if you want your work included in git.git, add a
+	  "Signed-off-by: Your Name <your@email.com>" line to the
+	  commit message (or just use the option "-s" when
+	  committing) to confirm that you agree to the Developer's
+	  Certificate of Origin
+	- do not PGP sign your patch
+	- use "git format-patch -M" to create the patch
+	- do not attach your patch, but read in the mail
+	  body, unless you cannot teach your mailer to
+	  leave the formatting of the patch alone.
+	- be careful doing cut & paste into your mailer, not to
+	  corrupt whitespaces.
+	- provide additional information (which is unsuitable for
+	  the commit message) between the "---" and the diffstat
+	- send the patch to the list _and_ the maintainer
+
+Long version:
+
 I started reading over the SubmittingPatches document for Linux
 kernel, primarily because I wanted to have a document similar to
 it for the core GIT to make sure people understand what they are

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-config.txt

@@ -78,7 +78,7 @@ OPTIONS
 	Remove the line matching the key from config file.
 
 --unset-all::
-	Remove all matching lines from config file.
+	Remove all lines matching the key from config file.
 
 -l, --list::
 	List all variables set in config file.

Documentation/git-cvsserver.txt

@@ -121,10 +121,10 @@ so that calling 'cvs' effectively calls git-cvsserver.
 Clients known to work
 ---------------------
 
-CVS 1.12.9 on Debian
-CVS 1.11.17 on MacOSX (from Fink package)
-Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
-TortoiseCVS
+- CVS 1.12.9 on Debian
+- CVS 1.11.17 on MacOSX (from Fink package)
+- Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
+- TortoiseCVS
 
 Operations supported
 --------------------
@@ -148,13 +148,16 @@ Copyright and Authors
 
 This program is copyright The Open University UK - 2006.
 
-Authors: Martyn Smith    <martyn@catalyst.net.nz>
-         Martin Langhoff <martin@catalyst.net.nz>
-         with ideas and patches from participants of the git-list <git@vger.kernel.org>.
+Authors:
+
+- Martyn Smith    <martyn@catalyst.net.nz>
+- Martin Langhoff <martin@catalyst.net.nz>
+
+with ideas and patches from participants of the git-list <git@vger.kernel.org>.
 
 Documentation
 --------------
-Documentation by Martyn Smith <martyn@catalyst.net.nz> and Martin Langhoff <martin@catalyst.net.nz> Matthias Urlichs <smurf@smurf.noris.de>.
+Documentation by Martyn Smith <martyn@catalyst.net.nz>, Martin Langhoff <martin@catalyst.net.nz>, and Matthias Urlichs <smurf@smurf.noris.de>.
 
 GIT
 ---

Documentation/git-diff.txt

@@ -8,7 +8,7 @@ git-diff - Show changes between commits, commit and working tree, etc
 
 SYNOPSIS
 --------
-'git-diff' [ --diff-options ] <commit>{0,2} [--] [<path>...]
+'git-diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
 
 DESCRIPTION
 -----------

Documentation/git-fast-import.txt

@@ -451,7 +451,7 @@ in octal.  Git only supports the following modes:
 In both formats `<path>` is the complete path of the file to be added
 (if not already existing) or modified (if already existing).
 
-A `<path>` string must use UNIX-style directory seperators (forward
+A `<path>` string must use UNIX-style directory separators (forward
 slash `/`), may contain any byte other than `LF`, and must not
 start with double quote (`"`).
 
@@ -461,8 +461,8 @@ quoting should be used, e.g. `"path/with\n and \" in it"`.
 The value of `<path>` must be in canoncial form. That is it must not:
 
 * contain an empty directory component (e.g. `foo//bar` is invalid),
-* end with a directory seperator (e.g. `foo/` is invalid),
-* start with a directory seperator (e.g. `/foo` is invalid),
+* end with a directory separator (e.g. `foo/` is invalid),
+* start with a directory separator (e.g. `/foo` is invalid),
 * contain the special component `.` or `..` (e.g. `foo/./bar` and
   `foo/../bar` are invalid).
 

Documentation/git-format-patch.txt

@@ -9,8 +9,8 @@ git-format-patch - Prepare patches for e-mail submission
 SYNOPSIS
 --------
 [verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [--thread]
-	           [-s | --signoff] [--diff-options] [--start-number <n>]
+'git-format-patch' [<common diff options>] [-n | -k] [-o <dir> | --stdout]
+		   [--attach] [--thread] [-s | --signoff] [--start-number <n>]
 		   [--in-reply-to=Message-Id] [--suffix=.<sfx>]
 		   [--ignore-if-in-upstream]
 		   <since>[..<until>]
@@ -46,6 +46,8 @@ reference.
 
 OPTIONS
 -------
+include::diff-options.txt[]
+
 -o|--output-directory <dir>::
 	Use <dir> to store the resulting files, instead of the
 	current working directory.

Documentation/git-send-email.txt

@@ -91,6 +91,19 @@ The --cc option must be repeated for each user you want on the cc list.
 The --to option must be repeated for each user you want on the to list.
 
 
+CONFIGURATION
+-------------
+sendemail.aliasesfile::
+	To avoid typing long email addresses, point this to one or more
+	email aliases files.  You must also supply 'sendemail.aliasfiletype'.
+
+sendemail.aliasfiletype::
+	Format of the file(s) specified in sendemail.aliasesfile. Must be
+	one of 'mutt', 'mailrc', 'pine', or 'gnus'.
+
+sendemail.smtpserver::
+	Default smtp server to use.
+
 Author
 ------
 Written by Ryan Anderson <ryan@michonline.com>

Documentation/git.txt

@@ -231,6 +231,12 @@ Identifier Terminology
 	operate on a <tree> object but automatically dereferences
 	<commit> and <tag> objects that point at a <tree>.
 
+<commit-ish>::
+	Indicates a commit or tag object name.  A
+	command that takes a <commit-ish> argument ultimately wants to
+	operate on a <commit> object but automatically dereferences
+	<tag> objects that point at a <commit>.
+
 <type>::
 	Indicates that an object type is required.
 	Currently one of: `blob`, `tree`, `commit`, or `tag`.

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/install-webdoc.sh

@@ -2,7 +2,7 @@
 
 T="$1"
 
-for h in *.html *.txt howto/*.txt howto/*.html RelNotes-*.txt
+for h in *.html *.txt howto/*.txt howto/*.html RelNotes-*.txt *.css
 do
 	if test -f "$T/$h" &&
 	   diff -u -I'Last updated [0-9][0-9]-[A-Z][a-z][a-z]-' "$T/$h" "$h"

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(?<!link:git-)',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
 ------------------------------
@@ -437,11 +438,14 @@ We will sometimes represent git history using diagrams like the one
 below.  Commits are shown as "o", and the links between them with
 lines drawn with - / and \.  Time goes left to right:
 
+
+................................................
          o--o--o <-- Branch A
         /
  o--o--o <-- master
         \
          o--o--o <-- Branch B
+................................................
 
 If we need to talk about a particular commit, the character "o" may
 be replaced with another letter or number.
@@ -449,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
 ---------------------
@@ -601,8 +603,8 @@ a new stanza:
 $ cat .git/config
 ...
 [remote "linux-nfs"]
-        url = git://linux-nfs.org/~bfields/git.git
-	fetch = +refs/heads/*:refs/remotes/linux-nfs-read/*
+	url = git://linux-nfs.org/pub/nfs-2.6.git
+	fetch = +refs/heads/*:refs/remotes/linux-nfs/*
 ...
 -------------------------------------------------
 
@@ -1133,17 +1135,9 @@ modified in two different ways in the remote branch and the local
 branch--then you are warned; the output may look something like this:
 
 -------------------------------------------------
-$ git pull . next
-Trying really trivial in-index merge...
-fatal: Merge requires file-level merging
-Nope.
-Merging HEAD with 77976da35a11db4580b80ae27e8d65caf5208086
-Merging:
-15e2162 world
-77976da goodbye
-found 1 common ancestor(s):
-d122ed4 initial
-Auto-merging file.txt
+$ git merge next
+ 100% (4/4) done
+Auto-merged file.txt
 CONFLICT (content): Merge conflict in file.txt
 Automatic merge failed; fix conflicts and then commit the result.
 -------------------------------------------------
@@ -1439,7 +1433,7 @@ modifying the working directory, you can do that with
 gitlink:git-show[1]:
 
 -------------------------------------------------
-$ git show HEAD^ path/to/file
+$ git show HEAD^:path/to/file
 -------------------------------------------------
 
 which will display the given version of the file.
@@ -1703,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
 
 -------------------------------------------------
@@ -1936,25 +1930,29 @@ $ git commit
 You have performed no merges into mywork, so it is just a simple linear
 sequence of patches on top of "origin":
 
-
+................................................
  o--o--o <-- origin
         \
          o--o--o <-- mywork
+................................................
 
 Some more interesting work has been done in the upstream project, and
 "origin" has advanced:
 
+................................................
  o--o--O--o--o--o <-- origin
         \
          a--b--c <-- mywork
+................................................
 
 At this point, you could use "pull" to merge your changes back in;
 the result would create a new merge commit, like this:
 
-
+................................................
  o--o--O--o--o--o <-- origin
         \        \
          a--b--c--m <-- mywork
+................................................
  
 However, if you prefer to keep the history in mywork a simple series of
 commits without any merges, you may instead choose to use
@@ -1971,9 +1969,11 @@ point at the latest version of origin, then apply each of the saved
 patches to the new mywork.  The result will look like:
 
 
+................................................
  o--o--O--o--o--o <-- origin
 		 \
 		  a'--b'--c' <-- mywork
+................................................
 
 In the process, it may discover conflicts.  In that case it will stop
 and allow you to fix the conflicts; after fixing conflicts, use "git
@@ -2081,24 +2081,30 @@ The primary problem with rewriting the history of a branch has to do
 with merging.  Suppose somebody fetches your branch and merges it into
 their branch, with a result something like this:
 
+................................................
  o--o--O--o--o--o <-- origin
         \        \
          t--t--t--m <-- their branch:
+................................................
 
 Then suppose you modify the last three commits:
 
+................................................
 	 o--o--o <-- new head of origin
 	/
  o--o--O--o--o--o <-- old head of origin
+................................................
 
 If we examined all this history together in one repository, it will
 look like:
 
+................................................
 	 o--o--o <-- new head of origin
 	/
  o--o--O--o--o--o <-- old head of origin
         \        \
          t--t--t--m <-- their branch:
+................................................
 
 Git has no way of knowing that the new head is an updated version of
 the old head; it treats this situation exactly the same as it would if
@@ -2159,9 +2165,11 @@ commit.  Git calls this process a "fast forward".
 
 A fast forward looks something like this:
 
+................................................
  o--o--o--o <-- old head of the branch
            \
             o--o--o <-- new head of the branch
+................................................
 
 
 In some cases it is possible that the new head will *not* actually be
@@ -2169,11 +2177,11 @@ a descendant of the old head.  For example, the developer may have
 realized she made a serious mistake, and decided to backtrack,
 resulting in a situation like:
 
+................................................
  o--o--o--o--a--b <-- old head of the branch
            \
             o--o--o <-- new head of the branch
-
-
+................................................
 
 In this case, "git fetch" will fail, and print out a warning.
 
@@ -3004,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.3.GIT
+DEF_VER=v1.5.0.6.GIT
 
 LF='
 '

Makefile

@@ -901,8 +901,7 @@ dist: git.spec git-archive
 	$(TAR) rf $(GIT_TARNAME).tar \
 		$(GIT_TARNAME)/git.spec \
 		$(GIT_TARNAME)/version \
-		$(GIT_TARNAME)/git-gui/version \
-		$(GIT_TARNAME)/git-gui/credits
+		$(GIT_TARNAME)/git-gui/version
 	@rm -rf $(GIT_TARNAME)
 	gzip -f -9 $(GIT_TARNAME).tar
 

RelNotes

@@ -1 +1 @@
-Documentation/RelNotes-1.5.0.3.txt
+Documentation/RelNotes-1.5.0.6.txt

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)

contrib/emacs/git.el

@@ -891,36 +891,77 @@ and returns the process output as a string."
   (with-current-buffer log-edit-parent-buffer
     (git-get-filenames (git-marked-files-state 'added 'deleted 'modified))))
 
+(defun git-append-sign-off (name email)
+  "Append a Signed-off-by entry to the current buffer, avoiding duplicates."
+  (let ((sign-off (format "Signed-off-by: %s <%s>" name email))
+        (case-fold-search t))
+    (goto-char (point-min))
+    (unless (re-search-forward (concat "^" (regexp-quote sign-off)) nil t)
+      (goto-char (point-min))
+      (unless (re-search-forward "^Signed-off-by: " nil t)
+        (setq sign-off (concat "\n" sign-off)))
+      (goto-char (point-max))
+      (insert sign-off "\n"))))
+
+(defun git-setup-log-buffer (buffer &optional author-name author-email subject date msg)
+  "Setup the log buffer for a commit."
+  (unless git-status (error "Not in git-status buffer."))
+  (let ((merge-heads (git-get-merge-heads))
+        (dir default-directory)
+        (committer-name (git-get-committer-name))
+        (committer-email (git-get-committer-email))
+        (sign-off git-append-signed-off-by))
+    (with-current-buffer buffer
+      (cd dir)
+      (erase-buffer)
+      (insert
+       (propertize
+        (format "Author: %s <%s>\n%s%s"
+                (or author-name committer-name)
+                (or author-email committer-email)
+                (if date (format "Date: %s\n" date) "")
+                (if merge-heads
+                    (format "Parent: %s\n%s\n"
+                            (git-rev-parse "HEAD")
+                            (mapconcat (lambda (str) (concat "Parent: " str)) merge-heads "\n"))
+                  ""))
+        'face 'git-header-face)
+       (propertize git-log-msg-separator 'face 'git-separator-face)
+       "\n")
+      (when subject (insert subject "\n\n"))
+      (cond (msg (insert msg "\n"))
+            ((file-readable-p ".dotest/msg")
+             (insert-file-contents ".dotest/msg"))
+            ((file-readable-p ".git/MERGE_MSG")
+             (insert-file-contents ".git/MERGE_MSG")))
+      ; delete empty lines at end
+      (goto-char (point-min))
+      (when (re-search-forward "\n+\\'" nil t)
+        (replace-match "\n" t t))
+      (when sign-off (git-append-sign-off committer-name committer-email)))))
+
 (defun git-commit-file ()
   "Commit the marked file(s), asking for a commit message."
   (interactive)
   (unless git-status (error "Not in git-status buffer."))
   (let ((buffer (get-buffer-create "*git-commit*"))
-        (merge-heads (git-get-merge-heads))
-        (dir default-directory)
         (coding-system (git-get-commits-coding-system))
-        (sign-off git-append-signed-off-by))
-    (with-current-buffer buffer
-      (when (eq 0 (buffer-size))
-        (cd dir)
-        (erase-buffer)
-        (insert
-         (propertize
-          (format "Author: %s <%s>\n%s"
-                  (git-get-committer-name) (git-get-committer-email)
-                  (if merge-heads
-                      (format "Parent: %s\n%s\n"
-                              (git-rev-parse "HEAD")
-                              (mapconcat (lambda (str) (concat "Parent: " str)) merge-heads "\n"))
-                    ""))
-          'face 'git-header-face)
-         (propertize git-log-msg-separator 'face 'git-separator-face)
-         "\n")
-        (cond ((file-readable-p ".git/MERGE_MSG")
-               (insert-file-contents ".git/MERGE_MSG"))
-              (sign-off
-               (insert (format "\n\nSigned-off-by: %s <%s>\n"
-                               (git-get-committer-name) (git-get-committer-email)))))))
+        author-name author-email subject date)
+    (when (eq 0 (buffer-size buffer))
+      (when (file-readable-p ".dotest/info")
+        (with-temp-buffer
+          (insert-file-contents ".dotest/info")
+          (goto-char (point-min))
+          (when (re-search-forward "^Author: \\(.*\\)\nEmail: \\(.*\\)$" nil t)
+            (setq author-name (match-string 1))
+            (setq author-email (match-string 2)))
+          (goto-char (point-min))
+          (when (re-search-forward "^Subject: \\(.*\\)$" nil t)
+            (setq subject (match-string 1)))
+          (goto-char (point-min))
+          (when (re-search-forward "^Date: \\(.*\\)$" nil t)
+            (setq date (match-string 1)))))
+      (git-setup-log-buffer buffer author-name author-email subject date))
     (log-edit #'git-do-commit nil #'git-log-edit-files buffer)
     (setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
     (setq buffer-file-coding-system coding-system)

fast-import.c

@@ -220,7 +220,8 @@ struct branch
 	const char *name;
 	struct tree_entry branch_tree;
 	uintmax_t last_commit;
-	unsigned int pack_id;
+	unsigned active : 1;
+	unsigned pack_id : PACK_ID_BITS;
 	unsigned char sha1[20];
 };
 
@@ -528,6 +529,7 @@ static struct branch *new_branch(const char *name)
 	b->table_next_branch = branch_table[hc];
 	b->branch_tree.versions[0].mode = S_IFDIR;
 	b->branch_tree.versions[1].mode = S_IFDIR;
+	b->active = 0;
 	b->pack_id = MAX_PACK_ID;
 	branch_table[hc] = b;
 	branch_count++;
@@ -1060,7 +1062,7 @@ static void load_tree(struct tree_entry *root)
 		struct tree_entry *e = new_tree_entry();
 
 		if (t->entry_count == t->entry_capacity)
-			root->tree = t = grow_tree_content(t, 8);
+			root->tree = t = grow_tree_content(t, t->entry_count);
 		t->entries[t->entry_count++] = e;
 
 		e->tree = NULL;
@@ -1227,7 +1229,7 @@ static int tree_content_set(
 	}
 
 	if (t->entry_count == t->entry_capacity)
-		root->tree = t = grow_tree_content(t, 8);
+		root->tree = t = grow_tree_content(t, t->entry_count);
 	e = new_tree_entry();
 	e->name = to_atom(p, (unsigned short)n);
 	e->versions[0].mode = 0;
@@ -1547,6 +1549,7 @@ static void unload_one_branch(void)
 			e = active_branches;
 			active_branches = e->active_next_branch;
 		}
+		e->active = 0;
 		e->active_next_branch = NULL;
 		if (e->branch_tree.tree) {
 			release_tree_content_recursive(e->branch_tree.tree);
@@ -1559,10 +1562,13 @@ static void unload_one_branch(void)
 static void load_branch(struct branch *b)
 {
 	load_tree(&b->branch_tree);
-	b->active_next_branch = active_branches;
-	active_branches = b;
-	cur_active_branches++;
-	branch_load_count++;
+	if (!b->active) {
+		b->active = 1;
+		b->active_next_branch = active_branches;
+		active_branches = b;
+		cur_active_branches++;
+		branch_load_count++;
+	}
 }
 
 static void file_change_m(struct branch *b)
@@ -1746,7 +1752,14 @@ static struct hash_list *cmd_merge(unsigned int *count)
 			if (oe->type != OBJ_COMMIT)
 				die("Mark :%" PRIuMAX " not a commit", idnum);
 			hashcpy(n->sha1, oe->sha1);
-		} else if (get_sha1(from, n->sha1))
+		} else if (!get_sha1(from, n->sha1)) {
+			unsigned long size;
+			char *buf = read_object_with_reference(n->sha1,
+				type_names[OBJ_COMMIT], &size, n->sha1);
+			if (!buf || size < 46)
+				die("Not a valid commit: %s", from);
+			free(buf);
+		} else
 			die("Invalid ref name or SHA1 expression: %s", from);
 
 		n->next = NULL;

git-checkout.sh

@@ -196,7 +196,7 @@ else
 	work=`git write-tree` &&
 	git read-tree --reset -u $new || exit
 
-	eval GITHEAD_$new=${new_name:-${branch:-$new}} &&
+	eval GITHEAD_$new='${new_name:-${branch:-$new}}' &&
 	eval GITHEAD_$work=local &&
 	export GITHEAD_$new GITHEAD_$work &&
 	git merge-recursive $old -- $new $work

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
@@ -621,6 +621,9 @@ else
 fi
 ret="$?"
 rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
+
+cd_to_toplevel
+
 if test -d "$GIT_DIR/rr-cache"
 then
 	git-rerere

git-gui/.gitignore

@@ -1,4 +1,3 @@
-CREDITS-FILE
 GIT-VERSION-FILE
 git-citool
 git-gui

git-gui/CREDITS-GEN

@@ -1,71 +0,0 @@
-#!/bin/sh
-
-CF=CREDITS-FILE
-tip=
-
-tree_search ()
-{
-	head=$1
-	tree=$2
-	for p in $(git rev-list --parents --max-count=1 $head 2>/dev/null)
-	do
-		test $tree = $(git rev-parse $p^{tree} 2>/dev/null) &&
-		vn=$(git describe --abbrev=4 $p 2>/dev/null) &&
-		case "$vn" in
-		gitgui-[0-9]*) echo $p; break;;
-		esac
-	done
-}
-
-generate_credits ()
-{
-	tip=$1 &&
-	rm -f "$2" &&
-	git shortlog -n -s $tip | sed 's/: .*$//' >"$2" || exit
-}
-
-# Always use the tarball credits file if found, just
-# in case we are somehow contained in a larger git
-# repository that doesn't actually track our state.
-# (At least one package manager is doing this.)
-#
-# We may be a subproject, so try looking for the merge
-# commit that supplied this directory content if we are
-# not at the toplevel.  We probably will always be the
-# second parent in the commit, but we shouldn't rely on
-# that fact.
-#
-
-credits_tmp=/var/tmp/gitgui-credits-$$
-trap 'rm -f "$credits_tmp"' 0
-
-orig="$credits_tmp"
-
-if test -f credits
-then
-	orig=credits
-elif prefix="$(git rev-parse --show-prefix 2>/dev/null)" &&
-   test -n "$prefix" &&
-   head=$(git rev-list --max-count=1 HEAD -- . 2>/dev/null) &&
-   tree=$(git rev-parse --verify "HEAD:$prefix" 2>/dev/null) &&
-   tip=$(tree_search $head $tree) &&
-   test -n "$tip"
-then
-	generate_credits $tip "$orig" || exit
-elif tip="$(git rev-parse --verify HEAD 2>/dev/null)" &&
-   test -n "$tip"
-then
-	generate_credits $tip "$orig" || exit
-else
-	echo "error: Cannot locate authorship information." >&2
-	exit 1
-fi
-
-if test -f "$orig" && cmp -s "$orig" "$CF"
-then
-	: noop
-else
-	rm -f "$CF" &&
-	cat "$orig" >"$CF"
-fi
-

git-gui/Makefile

@@ -1,11 +1,15 @@
 all::
 
+# Define V=1 to have a more verbose compile.
+#
+
 GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
 	@$(SHELL_PATH) ./GIT-VERSION-GEN
 -include GIT-VERSION-FILE
 
+SCRIPT_SH = git-gui.sh
 GITGUI_BUILT_INS = git-citool
-ALL_PROGRAMS = git-gui $(GITGUI_BUILT_INS)
+ALL_PROGRAMS = $(GITGUI_BUILT_INS) $(patsubst %.sh,%,$(SCRIPT_SH))
 
 ifndef SHELL_PATH
 	SHELL_PATH = /bin/sh
@@ -19,27 +23,28 @@ ifndef INSTALL
 	INSTALL = install
 endif
 
+ifndef V
+	QUIET_GEN      = @echo '   ' GEN $@;
+	QUIET_BUILT_IN = @echo '   ' BUILTIN $@;
+endif
+
 DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
 gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
 SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
 
-git-gui: git-gui.sh GIT-VERSION-FILE CREDITS-FILE
-	rm -f $@ $@+
-	sed -n \
-		-e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
+	$(QUIET_GEN)rm -f $@ $@+ && \
+	sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
 		-e 's/@@GITGUI_VERSION@@/$(GITGUI_VERSION)/g' \
-		-e '1,/^set gitgui_credits /p' \
-		$@.sh >$@+
-	cat CREDITS-FILE >>$@+
-	sed -e '1,/^set gitgui_credits /d' $@.sh >>$@+
-	chmod +x $@+
+		$@.sh >$@+ && \
+	chmod +x $@+ && \
 	mv $@+ $@
 
-CREDITS-FILE: CREDITS-GEN .FORCE-CREDITS-FILE
-	$(SHELL_PATH) ./CREDITS-GEN
-
 $(GITGUI_BUILT_INS): git-gui
-	rm -f $@ && ln git-gui $@
+	$(QUIET_BUILT_IN)rm -f $@ && ln git-gui $@
+
+# These can record GITGUI_VERSION
+$(patsubst %.sh,%,$(SCRIPT_SH)): GIT-VERSION-FILE
 
 all:: $(ALL_PROGRAMS)
 
@@ -48,14 +53,12 @@ install: all
 	$(INSTALL) git-gui '$(DESTDIR_SQ)$(gitexecdir_SQ)'
 	$(foreach p,$(GITGUI_BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git-gui' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
 
-dist-version: CREDITS-FILE
+dist-version:
 	@mkdir -p $(TARDIR)
 	@echo $(GITGUI_VERSION) > $(TARDIR)/version
-	@cat CREDITS-FILE > $(TARDIR)/credits
 
 clean::
-	rm -f $(ALL_PROGRAMS) GIT-VERSION-FILE CREDITS-FILE
+	rm -f $(ALL_PROGRAMS) GIT-VERSION-FILE
 
 .PHONY: all install dist-version clean
 .PHONY: .FORCE-GIT-VERSION-FILE
-.PHONY: .FORCE-CREDITS-FILE

git-gui/git-gui.sh

@@ -19,9 +19,6 @@ GNU General Public License for more details.
 You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
 Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA}
-set gitgui_credits {
-Paul Mackerras
-}
 
 ######################################################################
 ##
@@ -302,6 +299,11 @@ proc ask_popup {msg} {
 ##
 ## version check
 
+if {{--version} eq $argv || {version} eq $argv} {
+	puts "git-gui version $appvers"
+	exit
+}
+
 set req_maj 1
 set req_min 5
 
@@ -1171,7 +1173,7 @@ File [short_path $path] cannot be committed by this program.
 		}
 		}
 	}
-	if {!$files_ready} {
+	if {!$files_ready && ![string match *merge $curType]} {
 		info_popup {No changes to commit.
 
 You must add at least 1 file before you can commit.
@@ -1267,6 +1269,24 @@ proc commit_committree {fd_wt curHEAD msg} {
 		return
 	}
 
+	# -- Verify this wasn't an empty change.
+	#
+	if {$commit_type eq {normal}} {
+		set old_tree [git rev-parse "$PARENT^{tree}"]
+		if {$tree_id eq $old_tree} {
+			info_popup {No changes to commit.
+
+No files were modified by this commit and it
+was not a merge commit.
+
+A rescan will be automatically started now.
+}
+			unlock_index
+			rescan {set ui_status_value {No changes to commit.}}
+			return
+		}
+	}
+
 	# -- Build the message.
 	#
 	set msg_p [gitdir COMMIT_EDITMSG]
@@ -1281,14 +1301,8 @@ proc commit_committree {fd_wt curHEAD msg} {
 	# -- Create the commit.
 	#
 	set cmd [list git commit-tree $tree_id]
-	set parents [concat $PARENT $MERGE_HEAD]
-	if {[llength $parents] > 0} {
-		foreach p $parents {
-			lappend cmd -p $p
-		}
-	} else {
-		# git commit-tree writes to stderr during initial commit.
-		lappend cmd 2>/dev/null
+	foreach p [concat $PARENT $MERGE_HEAD] {
+		lappend cmd -p $p
 	}
 	lappend cmd <$msg_p
 	if {[catch {set cmt_id [eval exec $cmd]} err]} {
@@ -4480,61 +4494,6 @@ proc do_commit {} {
 	commit_tree
 }
 
-proc do_credits {} {
-	global gitgui_credits
-
-	set w .credits_dialog
-
-	toplevel $w
-	wm geometry $w "+[winfo rootx .]+[winfo rooty .]"
-
-	label $w.header -text {git-gui Contributors} -font font_uibold
-	pack $w.header -side top -fill x
-
-	frame $w.buttons
-	button $w.buttons.close -text {Close} \
-		-font font_ui \
-		-command [list destroy $w]
-	pack $w.buttons.close -side right
-	pack $w.buttons -side bottom -fill x -pady 10 -padx 10
-
-	frame $w.credits
-	text $w.credits.t \
-		-background [$w.header cget -background] \
-		-yscrollcommand [list $w.credits.sby set] \
-		-width 20 \
-		-height 10 \
-		-wrap none \
-		-borderwidth 1 \
-		-relief solid \
-		-padx 5 -pady 5 \
-		-font font_ui
-	scrollbar $w.credits.sby -command [list $w.credits.t yview]
-	pack $w.credits.sby -side right -fill y
-	pack $w.credits.t -fill both -expand 1
-	pack $w.credits -side top -fill both -expand 1 -padx 5 -pady 5
-
-	label $w.desc \
-		-text "All portions are copyrighted by their respective authors
-and are distributed under the GNU General Public License." \
-		-padx 5 -pady 5 \
-		-justify left \
-		-anchor w \
-		-borderwidth 1 \
-		-relief solid \
-		-font font_ui
-	pack $w.desc -side top -fill x -padx 5 -pady 5
-
-	$w.credits.t insert end "[string trim $gitgui_credits]\n"
-	$w.credits.t conf -state disabled
-	$w.credits.t see 1.0
-
-	bind $w <Visibility> "grab $w; focus $w"
-	bind $w <Key-Escape> [list destroy $w]
-	wm title $w [$w.header cget -text]
-	tkwait window $w
-}
-
 proc do_about {} {
 	global appvers copyright
 	global tcl_patchLevel tk_patchLevel
@@ -4551,10 +4510,6 @@ proc do_about {} {
 	button $w.buttons.close -text {Close} \
 		-font font_ui \
 		-command [list destroy $w]
-	button $w.buttons.credits -text {Contributors} \
-		-font font_ui \
-		-command do_credits
-	pack $w.buttons.credits -side left
 	pack $w.buttons.close -side right
 	pack $w.buttons -side bottom -fill x -pady 10 -padx 10
 
@@ -5104,8 +5059,6 @@ enable_option branch
 enable_option transport
 
 switch -- $subcommand {
---version -
-version -
 browser -
 blame {
 	disable_option multicommit
@@ -5256,6 +5209,12 @@ if {[is_enabled branch]} {
 		-font font_ui
 	lappend disable_on_lock [list .mbar.branch entryconf \
 		[.mbar.branch index last] -state]
+
+	.mbar.branch add command -label {Reset...} \
+		-command do_reset_hard \
+		-font font_ui
+	lappend disable_on_lock [list .mbar.branch entryconf \
+		[.mbar.branch index last] -state]
 }
 
 # -- Commit Menu
@@ -5330,6 +5289,34 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {
 		[list .mbar.commit entryconf [.mbar.commit index last] -state]
 }
 
+# -- Merge Menu
+#
+if {[is_enabled branch]} {
+	menu .mbar.merge
+	.mbar.merge add command -label {Local Merge...} \
+		-command do_local_merge \
+		-font font_ui
+	lappend disable_on_lock \
+		[list .mbar.merge entryconf [.mbar.merge index last] -state]
+	.mbar.merge add command -label {Abort Merge...} \
+		-command do_reset_hard \
+		-font font_ui
+	lappend disable_on_lock \
+		[list .mbar.merge entryconf [.mbar.merge index last] -state]
+
+}
+
+# -- Transport Menu
+#
+if {[is_enabled transport]} {
+	menu .mbar.fetch
+
+	menu .mbar.push
+	.mbar.push add command -label {Push...} \
+		-command do_push_anywhere \
+		-font font_ui
+}
+
 if {[is_MacOSX]} {
 	# -- Apple Menu (Mac OS X only)
 	#
@@ -5442,11 +5429,6 @@ bind all <$M1B-Key-W> {destroy [winfo toplevel %W]}
 # -- Not a normal commit type invocation?  Do that instead!
 #
 switch -- $subcommand {
---version -
-version {
-	puts "git-gui version $appvers"
-	exit
-}
 browser {
 	if {[llength $argv] != 1} {
 		puts stderr "usage: $argv0 browser commit"
@@ -5502,28 +5484,6 @@ pack .branch.l1 -side left
 pack .branch.cb -side left -fill x
 pack .branch -side top -fill x
 
-if {[is_enabled branch]} {
-	menu .mbar.merge
-	.mbar.merge add command -label {Local Merge...} \
-		-command do_local_merge \
-		-font font_ui
-	lappend disable_on_lock \
-		[list .mbar.merge entryconf [.mbar.merge index last] -state]
-	.mbar.merge add command -label {Abort Merge...} \
-		-command do_reset_hard \
-		-font font_ui
-	lappend disable_on_lock \
-		[list .mbar.merge entryconf [.mbar.merge index last] -state]
-
-
-	menu .mbar.fetch
-
-	menu .mbar.push
-	.mbar.push add command -label {Push...} \
-		-command do_push_anywhere \
-		-font font_ui
-}
-
 # -- Main Window Layout
 #
 panedwindow .vpane -orient vertical

git-merge.sh

@@ -292,9 +292,14 @@ 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
+	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" "Fast forward" || exit
+	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 ) .

receive-pack.c

@@ -158,7 +158,10 @@ static int update(struct command *cmd)
 			cmd->error_string = "failed to lock";
 			return error("failed to lock %s", name);
 		}
-		write_ref_sha1(lock, new_sha1, "push");
+		if (write_ref_sha1(lock, new_sha1, "push")) {
+			cmd->error_string = "failed to write";
+			return -1; /* error() already called */
+		}
 		fprintf(stderr, "%s: %s -> %s\n", name, old_hex, new_hex);
 	}
 	return 0;

refs.c

@@ -921,6 +921,8 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
 				     log_file, strerror(errno));
 	}
 
+	adjust_shared_perm(log_file);
+
 	msglen = 0;
 	if (msg) {
 		/* clean up the message and make sure it is a single line */

setup.c

@@ -216,7 +216,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
 		die("Not a git repository: '%s'", gitdirenv);
 	}
 
-	if (!getcwd(cwd, sizeof(cwd)) || cwd[0] != '/')
+	if (!getcwd(cwd, sizeof(cwd)-1) || cwd[0] != '/')
 		die("Unable to read current working directory");
 
 	offset = len = strlen(cwd);

t/annotate-tests.sh

@@ -114,7 +114,8 @@ test_expect_success \
 test_expect_success \
     'some edit' \
     'mv file file.orig &&
-    sed -e "s/^3A/99/" -e "/^1A/d" < file.orig > file &&
+    sed -e "s/^3A/99/" -e "/^1A/d" -e "/^incomplete/d" < file.orig > file &&
+    echo "incomplete" | tr -d "\\012" >>file &&
     GIT_AUTHOR_NAME="D" git commit -a -m "edit"'
 
 test_expect_success \

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 |