From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 26 Jun 2013 22:07:48 +0000 (-0700)
Subject: Merge branch 'ph/builtin-srcs-are-in-subdir-these-days'
X-Git-Tag: v1.8.4-rc0~123
X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/2ddc898bc0d0c3f03b4aeeb34c33f652d95f2807?hp=-c

Merge branch 'ph/builtin-srcs-are-in-subdir-these-days'

* ph/builtin-srcs-are-in-subdir-these-days:
fix "builtin-*" references to be "builtin/*"
---

2ddc898bc0d0c3f03b4aeeb34c33f652d95f2807
diff --combined Documentation/git-log.txt
index 4687fe8192,1d119ec720..2ea79ba168
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@@ -9,7 -9,7 +9,7 @@@ git-log - Show commit log
  SYNOPSIS
  --------
  [verse]
 -'git log' [<options>] [<since>..<until>] [[\--] <path>...]
 +'git log' [<options>] [<revision range>] [[\--] <path>...]
  
  DESCRIPTION
  -----------
@@@ -24,6 -24,13 +24,6 @@@ each commit introduces are shown
  OPTIONS
  -------
  
 -<since>..<until>::
 -	Show only commits between the named two commits.  When
 -	either <since> or <until> is omitted, it defaults to
 -	`HEAD`, i.e. the tip of the current branch.
 -	For a more complete list of ways to spell <since>
 -	and <until>, see linkgit:gitrevisions[7].
 -
  --follow::
  	Continue listing the history of a file beyond renames
  	(works only for a single file).
@@@ -40,11 -47,6 +40,11 @@@
  	Print out the ref name given on the command line by which each
  	commit was reached.
  
 +--use-mailmap::
 +	Use mailmap file to map author and committer names and email
 +	to canonical real names and email addresses. See
 +	linkgit:git-shortlog[1].
 +
  --full-diff::
  	Without this flag, "git log -p <path>..." shows commits that
  	touch the specified paths, and diffs about the same specified
@@@ -57,41 -59,19 +57,41 @@@ produced by --stat etc
  
  --log-size::
  	Before the log message print out its size in bytes. Intended
 -	mainly for porcelain tools consumption. If git is unable to
 +	mainly for porcelain tools consumption. If Git is unable to
  	produce a valid value size is set to zero.
  	Note that only message is considered, if also a diff is shown
  	its size is not included.
  
 +-L <start>,<end>:<file>, -L :<regex>:<file>::
 +
 +	Trace the evolution of the line range given by "<start>,<end>"
 +	(or the funcname regex <regex>) within the <file>.  You may
 +	not give any pathspec limiters.  This is currently limited to
 +	a walk starting from a single revision, i.e., you may only
 +	give zero or one positive revision arguments.
 +	You can specify this option more than once.
 ++
 +<start> and <end> can take one of these forms:
 +
 +include::line-range-format.txt[]
 +
 +<revision range>::
 +	Show only commits in the specified revision range.  When no
 +	<revision range> is specified, it defaults to `HEAD` (i.e. the
 +	whole history leading to the current commit).  `origin..HEAD`
 +	specifies all the commits reachable from the current commit
 +	(i.e. `HEAD`), but not from `origin`. For a complete list of
 +	ways to spell <revision range>, see the "Specifying Ranges"
 +	section of linkgit:gitrevisions[7].
 +
  [\--] <path>...::
  	Show only commits that are enough to explain how the files
  	that match the specified paths came to be.  See "History
  	Simplification" below for details and other simplification
  	modes.
  +
 -To prevent confusion with options and branch names, paths may need to
 -be prefixed with "\-- " to separate them from options or refnames.
 +Paths may need to be prefixed with "\-- " to separate them from
 +options or the revision range, when confusion arises.
  
  include::rev-list-options.txt[]
  
@@@ -128,9 -108,9 +128,9 @@@ Example
  	in the "release" branch, along with the list of paths
  	each commit modifies.
  
- `git log --follow builtin-rev-list.c`::
+ `git log --follow builtin/rev-list.c`::
  
- 	Shows the commits that changed builtin-rev-list.c, including
+ 	Shows the commits that changed builtin/rev-list.c, including
  	those commits that occurred before the file was given its
  	present name.
  
@@@ -153,11 -133,6 +153,11 @@@
  	This makes sense only when following a strict policy of merging all
  	topic branches when staying on a single integration branch.
  
 +git log -L '/int main/',/^}/:main.c::
 +
 +	Shows how the function `main()` in the file 'main.c' evolved
 +	over time.
 +
  `git log -3`::
  	Limits the number of commits to show to 3.
  
@@@ -192,7 -167,7 +192,7 @@@ log.showroot:
  	`git log -p` output would be shown without a diff attached.
  	The default is `true`.
  
 -mailmap.file::
 +mailmap.*::
  	See linkgit:git-shortlog[1].
  
  notes.displayRef::
diff --combined Documentation/technical/api-builtin.txt
index 4a4228b896,790bb28af7..f3c1357b7c
--- a/Documentation/technical/api-builtin.txt
+++ b/Documentation/technical/api-builtin.txt
@@@ -5,7 -5,7 +5,7 @@@ Adding a new built-i
  ---------------------
  
  There are 4 things to do to add a built-in command implementation to
 -git:
 +Git:
  
  . Define the implementation of the built-in command `foo` with
    signature:
@@@ -23,7 -23,7 +23,7 @@@ where options is the bitwise-or of
  
  `RUN_SETUP`::
  
 -	Make sure there is a git directory to work on, and if there is a
 +	Make sure there is a Git directory to work on, and if there is a
  	work tree, chdir to the top of it if the command was invoked
  	in a subdirectory.  If there is no work tree, no chdir() is
  	done.
@@@ -39,7 -39,7 +39,7 @@@
  	on bare repositories.
  	This only makes sense when `RUN_SETUP` is also set.
  
- . Add `builtin-foo.o` to `BUILTIN_OBJS` in `Makefile`.
+ . Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`.
  
  Additionally, if `foo` is a new command, there are 3 more things to do:
  
diff --combined Documentation/technical/api-parse-options.txt
index 1317db4d6c,ceeace5836..0be2b5159f
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@@ -1,7 -1,7 +1,7 @@@
  parse-options API
  =================
  
 -The parse-options API is used to parse and massage options in git
 +The parse-options API is used to parse and massage options in Git
  and to provide a usage help with consistent look.
  
  Basics
@@@ -41,8 -41,6 +41,8 @@@ The parse-options API allows
  * Boolean long options can be 'negated' (or 'unset') by prepending
    `no-`, e.g. `--no-abbrev` instead of `--abbrev`. Conversely,
    options that begin with `no-` can be 'negated' by removing it.
 +  Other long options can be unset (e.g., set string to NULL, set
 +  integer to 0) by prepending `no-`.
  
  * Options and non-option arguments can clearly be separated using the `--`
    option, e.g. `-a -b --option -- --this-is-a-file` indicates that
@@@ -176,10 -174,6 +176,10 @@@ There are some macros to easily define 
  	Introduce an option with date argument, see `approxidate()`.
  	The timestamp is put into `int_var`.
  
 +`OPT_EXPIRY_DATE(short, long, &int_var, description)`::
 +	Introduce an option with expiry date argument, see `parse_expiry_date()`.
 +	The timestamp is put into `int_var`.
 +
  `OPT_CALLBACK(short, long, &var, arg_str, description, func_ptr)`::
  	Introduce an option with argument.
  	The argument will be fed into the function given by `func_ptr`
@@@ -275,10 -269,10 +275,10 @@@ Example
  --------
  
  See `test-parse-options.c` and
- `builtin-add.c`,
- `builtin-clone.c`,
- `builtin-commit.c`,
- `builtin-fetch.c`,
- `builtin-fsck.c`,
- `builtin-rm.c`
+ `builtin/add.c`,
+ `builtin/clone.c`,
+ `builtin/commit.c`,
+ `builtin/fetch.c`,
+ `builtin/fsck.c`,
+ `builtin/rm.c`
  for real-world examples.
diff --combined Documentation/user-manual.txt
index e831cc2020,ac6f3605a9..2436124de2
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@@ -5,7 -5,7 +5,7 @@@ _______________________________________
  Git is a fast distributed revision control system.
  
  This manual is designed to be readable by someone with basic UNIX
 -command-line skills, but no previous knowledge of git.
 +command-line skills, but no previous knowledge of Git.
  
  <<repositories-and-branches>> and <<exploring-git-history>> explain how
  to fetch and study a project using git--read these chapters to learn how
@@@ -19,7 -19,7 +19,7 @@@ Further chapters cover more specialize
  
  Comprehensive reference documentation is available through the man
  pages, or linkgit:git-help[1] command.  For example, for the command
 -"git clone <repo>", you can either use:
 +`git clone <repo>`, you can either use:
  
  ------------------------------------------------
  $ man git-clone
@@@ -34,7 -34,7 +34,7 @@@ $ git help clon
  With the latter, you can use the manual viewer of your choice; see
  linkgit:git-help[1] for more information.
  
 -See also <<git-quick-start>> for a brief overview of git commands,
 +See also <<git-quick-start>> for a brief overview of Git commands,
  without any explanation.
  
  Finally, see <<todo>> for ways that you can help make this manual more
@@@ -46,10 -46,10 +46,10 @@@ Repositories and Branche
  =========================
  
  [[how-to-get-a-git-repository]]
 -How to get a git repository
 +How to get a Git repository
  ---------------------------
  
 -It will be useful to have a git repository to experiment with as you
 +It will be useful to have a Git repository to experiment with as you
  read this manual.
  
  The best way to get one is by using the linkgit:git-clone[1] command to
@@@ -57,7 -57,7 +57,7 @@@ download a copy of an existing reposito
  project in mind, here are some interesting examples:
  
  ------------------------------------------------
 -	# git itself (approx. 10MB download):
 +	# Git itself (approx. 10MB download):
  $ git clone git://git.kernel.org/pub/scm/git/git.git
  	# the Linux kernel (approx. 150MB download):
  $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
@@@ -66,11 -66,11 +66,11 @@@
  The initial clone may be time-consuming for a large project, but you
  will only need to clone once.
  
 -The clone command creates a new directory named after the project ("git"
 -or "linux-2.6" in the examples above).  After you cd into this
 +The clone command creates a new directory named after the project (`git`
 +or `linux-2.6` in the examples above).  After you cd into this
  directory, you will see that it contains a copy of the project files,
  called the <<def_working_tree,working tree>>, together with a special
 -top-level directory named ".git", which contains all the information
 +top-level directory named `.git`, which contains all the information
  about the history of the project.
  
  [[how-to-check-out]]
@@@ -79,7 -79,7 +79,7 @@@ How to check out a different version o
  
  Git is best thought of as a tool for storing the history of a collection
  of files.  It stores the history as a compressed collection of
 -interrelated snapshots of the project's contents.  In git each such
 +interrelated snapshots of the project's contents.  In Git each such
  version is called a <<def_commit,commit>>.
  
  Those snapshots aren't necessarily all arranged in a single line from
@@@ -87,7 -87,7 +87,7 @@@ oldest to newest; instead, work may sim
  parallel lines of development, called <<def_branch,branches>>, which may
  merge and diverge.
  
 -A single git repository can track development on multiple branches.  It
 +A single Git repository can track development on multiple branches.  It
  does this by keeping a list of <<def_head,heads>> which reference the
  latest commit on each branch; the linkgit:git-branch[1] command shows
  you the list of branch heads:
@@@ -188,7 -188,7 +188,7 @@@ As you can see, a commit shows who mad
  did, and why.
  
  Every commit has a 40-hexdigit id, sometimes called the "object name" or the
 -"SHA-1 id", shown on the first line of the "git show" output.  You can usually
 +"SHA-1 id", shown on the first line of the `git show` output.  You can usually
  refer to a commit by a shorter name, such as a tag or a branch name, but this
  longer name can also be useful.  Most importantly, it is a globally unique
  name for this commit: so if you tell somebody else the object name (for
@@@ -198,7 -198,7 +198,7 @@@ has that commit at all).  Since the obj
  contents of the commit, you are guaranteed that the commit can never change
  without its name also changing.
  
 -In fact, in <<git-concepts>> we shall see that everything stored in git
 +In fact, in <<git-concepts>> we shall see that everything stored in Git
  history, including file data and directory contents, is stored in an object
  with a name that is a hash of its contents.
  
@@@ -211,7 -211,7 +211,7 @@@ parent commit which shows what happene
  Following the chain of parents will eventually take you back to the
  beginning of the project.
  
 -However, the commits do not form a simple list; git allows lines of
 +However, the commits do not form a simple list; Git allows lines of
  development to diverge and then reconverge, and the point where two
  lines of development reconverge is called a "merge".  The commit
  representing a merge can therefore have more than one parent, with
@@@ -219,8 -219,8 +219,8 @@@ each parent representing the most recen
  of development leading to that point.
  
  The best way to see how this works is using the linkgit:gitk[1]
 -command; running gitk now on a git repository and looking for merge
 -commits will help understand how the git organizes history.
 +command; running gitk now on a Git repository and looking for merge
 +commits will help understand how the Git organizes history.
  
  In the following, we say that commit X is "reachable" from commit Y
  if commit X is an ancestor of commit Y.  Equivalently, you could say
@@@ -231,7 -231,7 +231,7 @@@ leading from commit Y to commit X
  Understanding history: History diagrams
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
 -We will sometimes represent git history using diagrams like the one
 +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:
  
@@@ -268,35 -268,35 +268,35 @@@ Manipulating branche
  Creating, deleting, and modifying branches is quick and easy; here's
  a summary of the commands:
  
 -git branch::
 +`git branch`::
  	list all branches
 -git branch <branch>::
 -	create a new branch named <branch>, referencing the same
 +`git branch <branch>`::
 +	create a new branch named `<branch>`, referencing the same
  	point in history as the current branch
 -git branch <branch> <start-point>::
 -	create a new branch named <branch>, referencing
 -	<start-point>, which may be specified any way you like,
 +`git branch <branch> <start-point>`::
 +	create a new branch named `<branch>`, referencing
 +	`<start-point>`, which may be specified any way you like,
  	including using a branch name or a tag name
 -git branch -d <branch>::
 -	delete the branch <branch>; if the branch you are deleting
 +`git branch -d <branch>`::
 +	delete the branch `<branch>`; if the branch you are deleting
  	points to a commit which is not reachable from the current
  	branch, this command will fail with a warning.
 -git branch -D <branch>::
 +`git branch -D <branch>`::
  	even if the branch points to a commit not reachable
  	from the current branch, you may know that that commit
  	is still reachable from some other branch or tag.  In that
 -	case it is safe to use this command to force git to delete
 +	case it is safe to use this command to force Git to delete
  	the branch.
 -git checkout <branch>::
 -	make the current branch <branch>, updating the working
 -	directory to reflect the version referenced by <branch>
 -git checkout -b <new> <start-point>::
 -	create a new branch <new> referencing <start-point>, and
 +`git checkout <branch>`::
 +	make the current branch `<branch>`, updating the working
 +	directory to reflect the version referenced by `<branch>`
 +`git checkout -b <new> <start-point>`::
 +	create a new branch `<new>` referencing `<start-point>`, and
  	check it out.
  
  The special symbol "HEAD" can always be used to refer to the current
 -branch.  In fact, git uses a file named "HEAD" in the .git directory to
 -remember which branch is current:
 +branch.  In fact, Git uses a file named `HEAD` in the `.git` directory
 +to remember which branch is current:
  
  ------------------------------------------------
  $ cat .git/HEAD
@@@ -346,7 -346,7 +346,7 @@@ of the HEAD in the repository that you 
  may also have had other branches, though, and your local repository
  keeps branches which track each of those remote branches, called
  remote-tracking branches, which you
 -can view using the "-r" option to linkgit:git-branch[1]:
 +can view using the `-r` option to linkgit:git-branch[1]:
  
  ------------------------------------------------
  $ git branch -r
@@@ -364,7 -364,7 +364,7 @@@ In this example, "origin" is called a r
  for short. The branches of this repository are called "remote
  branches" from our point of view. The remote-tracking branches listed
  above were created based on the remote branches at clone time and will
 -be updated by "git fetch" (hence "git pull") and "git push". See
 +be updated by `git fetch` (hence `git pull`) and `git push`. See
  <<Updating-a-repository-With-git-fetch>> for details.
  
  You might want to build on one of these remote-tracking branches
@@@ -374,10 -374,10 +374,10 @@@ on a branch of your own, just as you wo
  $ git checkout -b my-todo-copy origin/todo
  ------------------------------------------------
  
 -You can also check out "origin/todo" directly to examine it or
 +You can also check out `origin/todo` directly to examine it or
  write a one-off patch.  See <<detached-head,detached head>>.
  
 -Note that the name "origin" is just the name that git uses by default
 +Note that the name "origin" is just the name that Git uses by default
  to refer to the repository that you cloned from.
  
  [[how-git-stores-references]]
@@@ -386,17 -386,17 +386,17 @@@ Naming branches, tags, and other refere
  
  Branches, remote-tracking branches, and tags are all references to
  commits.  All references are named with a slash-separated path name
 -starting with "refs"; the names we've been using so far are actually
 +starting with `refs`; the names we've been using so far are actually
  shorthand:
  
 -	- The branch "test" is short for "refs/heads/test".
 -	- The tag "v2.6.18" is short for "refs/tags/v2.6.18".
 -	- "origin/master" is short for "refs/remotes/origin/master".
 +	- The branch `test` is short for `refs/heads/test`.
 +	- The tag `v2.6.18` is short for `refs/tags/v2.6.18`.
 +	- `origin/master` is short for `refs/remotes/origin/master`.
  
  The full name is occasionally useful if, for example, there ever
  exists a tag and a branch with the same name.
  
 -(Newly created refs are actually stored in the .git/refs directory,
 +(Newly created refs are actually stored in the `.git/refs` directory,
  under the path given by their name.  However, for efficiency reasons
  they may also be packed together in a single file; see
  linkgit:git-pack-refs[1]).
@@@ -405,7 -405,7 +405,7 @@@ As another useful shortcut, the "HEAD" 
  to just using the name of that repository.  So, for example, "origin"
  is usually a shortcut for the HEAD branch in the repository "origin".
  
 -For the complete list of paths which git checks for references, and
 +For the complete list of paths which Git checks for references, and
  the order it uses to decide which to choose when there are multiple
  references with the same shorthand name, see the "SPECIFYING
  REVISIONS" section of linkgit:gitrevisions[7].
@@@ -418,7 -418,7 +418,7 @@@ Eventually the developer cloned from wi
  repository, creating new commits and advancing the branches to point
  at the new commits.
  
 -The command "git fetch", with no arguments, will update all of the
 +The command `git fetch`, with no arguments, will update all of the
  remote-tracking branches to the latest version found in her
  repository.  It will not touch any of your own branches--not even the
  "master" branch that was created for you on clone.
@@@ -438,7 -438,7 +438,7 @@@ $ git fetch linux-nf
  -------------------------------------------------
  
  New remote-tracking branches will be stored under the shorthand name
 -that you gave "git remote add", in this case linux-nfs:
 +that you gave `git remote add`, in this case `linux-nfs`:
  
  -------------------------------------------------
  $ git branch -r
@@@ -446,10 -446,10 +446,10 @@@ linux-nfs/maste
  origin/master
  -------------------------------------------------
  
 -If you run "git fetch <remote>" later, the remote-tracking branches for the
 -named <remote> will be updated.
 +If you run `git fetch <remote>` later, the remote-tracking branches
 +for the named `<remote>` will be updated.
  
 -If you examine the file .git/config, you will see that git has added
 +If you examine the file `.git/config`, you will see that Git has added
  a new stanza:
  
  -------------------------------------------------
@@@ -461,13 -461,13 +461,13 @@@ $ cat .git/confi
  ...
  -------------------------------------------------
  
 -This is what causes git to track the remote's branches; you may modify
 -or delete these configuration options by editing .git/config with a
 +This is what causes Git to track the remote's branches; you may modify
 +or delete these configuration options by editing `.git/config` with a
  text editor.  (See the "CONFIGURATION FILE" section of
  linkgit:git-config[1] for details.)
  
  [[exploring-git-history]]
 -Exploring git history
 +Exploring Git history
  =====================
  
  Git is best thought of as a tool for storing the history of a
@@@ -499,7 -499,7 +499,7 @@@ Bisecting: 3537 revisions left to test 
  [65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]
  -------------------------------------------------
  
 -If you run "git branch" at this point, you'll see that git has
 +If you run `git branch` at this point, you'll see that Git has
  temporarily moved you in "(no branch)". HEAD is now detached from any
  branch and points directly to a commit (with commit id 65934...) that
  is reachable from "master" but not from v2.6.18. Compile and test it,
@@@ -511,7 -511,7 +511,7 @@@ Bisecting: 1769 revisions left to test 
  [7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings
  -------------------------------------------------
  
 -checks out an older version.  Continue like this, telling git at each
 +checks out an older version.  Continue like this, telling Git at each
  stage whether the version it gives you is good or bad, and notice
  that the number of revisions left to test is cut approximately in
  half each time.
@@@ -545,24 -545,24 +545,24 @@@ id, and check it out with
  $ git reset --hard fb47ddb2db...
  -------------------------------------------------
  
 -then test, run "bisect good" or "bisect bad" as appropriate, and
 +then test, run `bisect good` or `bisect bad` as appropriate, and
  continue.
  
 -Instead of "git bisect visualize" and then "git reset --hard
 -fb47ddb2db...", you might just want to tell git that you want to skip
 +Instead of `git bisect visualize` and then `git reset --hard
 +fb47ddb2db...`, you might just want to tell Git that you want to skip
  the current commit:
  
  -------------------------------------------------
  $ git bisect skip
  -------------------------------------------------
  
 -In this case, though, git may not eventually be able to tell the first
 +In this case, though, Git may not eventually be able to tell the first
  bad one between some first skipped commits and a later bad commit.
  
  There are also ways to automate the bisecting process if you have a
  test script that can tell a good from a bad commit. See
 -linkgit:git-bisect[1] for more information about this and other "git
 -bisect" features.
 +linkgit:git-bisect[1] for more information about this and other `git
 +bisect` features.
  
  [[naming-commits]]
  Naming commits
@@@ -591,7 -591,7 +591,7 @@@ $ git show HEAD~4   # the great-great-g
  -------------------------------------------------
  
  Recall that merge commits may have more than one parent; by default,
 -^ and ~ follow the first parent listed in the commit, but you can
 +`^` and `~` follow the first parent listed in the commit, but you can
  also choose:
  
  -------------------------------------------------
@@@ -640,7 -640,7 +640,7 @@@ runnin
  $ git tag stable-1 1b2e1d63ff
  -------------------------------------------------
  
 -You can use stable-1 to refer to the commit 1b2e1d63ff.
 +You can use `stable-1` to refer to the commit 1b2e1d63ff.
  
  This creates a "lightweight" tag.  If you would also like to include a
  comment with the tag, and possibly sign it cryptographically, then you
@@@ -669,7 -669,7 +669,7 @@@ $ git log -S'foo()'	# commits which ad
  -------------------------------------------------
  
  And of course you can combine all of these; the following finds
 -commits since v2.5 which touch the Makefile or any file under fs:
 +commits since v2.5 which touch the `Makefile` or any file under `fs`:
  
  -------------------------------------------------
  $ git log v2.5.. Makefile fs/
@@@ -681,11 -681,11 +681,11 @@@ You can also ask git log to show patche
  $ git log -p
  -------------------------------------------------
  
 -See the "--pretty" option in the linkgit:git-log[1] man page for more
 +See the `--pretty` option in the linkgit:git-log[1] man page for more
  display options.
  
  Note that git log starts with the most recent commit and works
 -backwards through the parents; however, since git history can contain
 +backwards through the parents; however, since Git history can contain
  multiple independent lines of development, the particular order that
  commits are listed in may be somewhat arbitrary.
  
@@@ -732,7 -732,7 +732,7 @@@ $ git show v2.5:fs/locks.
  -------------------------------------------------
  
  Before the colon may be anything that names a commit, and after it
 -may be any path to a file tracked by git.
 +may be any path to a file tracked by Git.
  
  [[history-examples]]
  Examples
@@@ -742,8 -742,8 +742,8 @@@
  Counting the number of commits on a branch
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
 -Suppose you want to know how many commits you've made on "mybranch"
 -since it diverged from "origin":
 +Suppose you want to know how many commits you've made on `mybranch`
 +since it diverged from `origin`:
  
  -------------------------------------------------
  $ git log --pretty=oneline origin..mybranch | wc -l
@@@ -780,7 -780,7 +780,7 @@@ $ git rev-list maste
  e05db0fd4f31dde7005f075a84f96b360d05984b
  -------------------------------------------------
  
 -Or you could recall that the ... operator selects all commits
 +Or you could recall that the `...` operator selects all commits
  contained reachable from either one reference or the other but not
  both; so
  
@@@ -880,7 -880,7 +880,7 @@@ Showing commits unique to a given branc
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  Suppose you would like to see all the commits reachable from the branch
 -head named "master" but not from any other head in your repository.
 +head named `master` but not from any other head in your repository.
  
  We can list all the heads in this repository with
  linkgit:git-show-ref[1]:
@@@ -894,7 -894,7 +894,7 @@@ a07157ac624b2524a059a3414e99f6f44bebc1e
  1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes
  -------------------------------------------------
  
 -We can get just the branch-head names, and remove "master", with
 +We can get just the branch-head names, and remove `master`, with
  the help of the standard utilities cut and grep:
  
  -------------------------------------------------
@@@ -939,7 -939,7 +939,7 @@@ is preceded by `project/`.  The output 
  the output file extension if possible, see linkgit:git-archive[1] for
  details.
  
 -Versions of Git older than 1.7.7 don't know about the 'tar.gz' format,
 +Versions of Git older than 1.7.7 don't know about the `tar.gz` format,
  you'll need to use gzip explicitly:
  
  -------------------------------------------------
@@@ -993,11 -993,11 +993,11 @@@ student.  The linkgit:git-log[1], linkg
  linkgit:git-hash-object[1] man pages may prove helpful.
  
  [[Developing-With-git]]
 -Developing with git
 +Developing with Git
  ===================
  
  [[telling-git-your-name]]
 -Telling git your name
 +Telling Git your name
  ---------------------
  
  Before creating any commits, you should introduce yourself to Git.
@@@ -1052,17 -1052,17 +1052,17 @@@ Creating a new commit takes three steps
  
  	1. Making some changes to the working directory using your
  	   favorite editor.
 -	2. Telling git about your changes.
 -	3. Creating the commit using the content you told git about
 +	2. Telling Git about your changes.
 +	3. Creating the commit using the content you told Git about
  	   in step 2.
  
  In practice, you can interleave and repeat steps 1 and 2 as many
  times as you want: in order to keep track of what you want committed
 -at step 3, git maintains a snapshot of the tree's contents in a
 +at step 3, Git maintains a snapshot of the tree's contents in a
  special staging area called "the index."
  
  At the beginning, the content of the index will be identical to
 -that of the HEAD.  The command "git diff --cached", which shows
 +that of the HEAD.  The command `git diff --cached`, which shows
  the difference between the HEAD and the index, should therefore
  produce no output at that point.
  
@@@ -1101,7 -1101,7 +1101,7 @@@ $ git dif
  
  shows the difference between the working tree and the index file.
  
 -Note that "git add" always adds just the current contents of a file
 +Note that `git add` always adds just the current contents of a file
  to the index; further changes to the same file will be ignored unless
  you run `git add` on the file again.
  
@@@ -1111,7 -1111,7 +1111,7 @@@ When you're ready, just ru
  $ git commit
  -------------------------------------------------
  
 -and git will prompt you for a commit message and then create the new
 +and Git will prompt you for a commit message and then create the new
  commit.  Check to make sure it looks like what you expected with
  
  -------------------------------------------------
@@@ -1155,7 -1155,7 +1155,7 @@@ with a single short (less than 50 chara
  change, followed by a blank line and then a more thorough
  description.  The text up to the first blank line in a commit
  message is treated as the commit title, and that title is used
 -throughout git.  For example, linkgit:git-format-patch[1] turns a
 +throughout Git.  For example, linkgit:git-format-patch[1] turns a
  commit into email, and it uses the title on the Subject line and the
  rest of the commit in the body.
  
@@@ -1164,17 -1164,16 +1164,17 @@@
  Ignoring files
  --------------
  
 -A project will often generate files that you do 'not' want to track with git.
 +A project will often generate files that you do 'not' want to track with Git.
  This typically includes files generated by a build process or temporary
 -backup files made by your editor. Of course, 'not' tracking files with git
 +backup files made by your editor. Of course, 'not' tracking files with Git
  is just a matter of 'not' calling `git add` on them. But it quickly becomes
  annoying to have these untracked files lying around; e.g. they make
  `git add .` practically useless, and they keep showing up in the output of
  `git status`.
  
 -You can tell git to ignore certain files by creating a file called .gitignore
 -in the top level of your working directory, with contents such as:
 +You can tell Git to ignore certain files by creating a file called
 +`.gitignore` in the top level of your working directory, with contents
 +such as:
  
  -------------------------------------------------
  # Lines starting with '#' are considered comments.
@@@ -1198,10 -1197,10 +1198,10 @@@ for other users who clone your reposito
  
  If you wish the exclude patterns to affect only certain repositories
  (instead of every repository for a given project), you may instead put
 -them in a file in your repository named .git/info/exclude, or in any file
 -specified by the `core.excludesfile` configuration variable.  Some git
 -commands can also take exclude patterns directly on the command line.
 -See linkgit:gitignore[5] for the details.
 +them in a file in your repository named `.git/info/exclude`, or in any
 +file specified by the `core.excludesfile` configuration variable.
 +Some Git commands can also take exclude patterns directly on the
 +command line.  See linkgit:gitignore[5] for the details.
  
  [[how-to-merge]]
  How to merge
@@@ -1214,10 -1213,10 +1214,10 @@@ linkgit:git-merge[1]
  $ git merge branchname
  -------------------------------------------------
  
 -merges the development in the branch "branchname" into the current
 +merges the development in the branch `branchname` into the current
  branch.
  
 -A merge is made by combining the changes made in "branchname" and the
 +A merge is made by combining the changes made in `branchname` and the
  changes made up to the latest commit in your current branch since
  their histories forked. The work tree is overwritten by the result of
  the merge when this combining is done cleanly, or overwritten by a
@@@ -1245,7 -1244,7 +1245,7 @@@ Automatic merge failed; fix conflicts a
  
  Conflict markers are left in the problematic files, and after
  you resolve the conflicts manually, you can update the index
 -with the contents and run git commit, as you normally would when
 +with the contents and run Git commit, as you normally would when
  creating a new file.
  
  If you examine the resulting commit using gitk, you will see that it
@@@ -1256,7 -1255,7 +1256,7 @@@ one to the top of the other branch
  Resolving a merge
  -----------------
  
 -When a merge isn't resolved automatically, git leaves the index and
 +When a merge isn't resolved automatically, Git leaves the index and
  the working tree in a special state that gives you all the
  information you need to help resolve the merge.
  
@@@ -1292,14 -1291,14 +1292,14 @@@ some information about the merge.  Norm
  default message unchanged, but you may add additional commentary of
  your own if desired.
  
 -The above is all you need to know to resolve a simple merge.  But git
 +The above is all you need to know to resolve a simple merge.  But Git
  also provides more information to help resolve conflicts:
  
  [[conflict-resolution]]
  Getting conflict-resolution help during a merge
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
 -All of the changes that git was able to merge automatically are
 +All of the changes that Git was able to merge automatically are
  already added to the index file, so linkgit:git-diff[1] shows only
  the conflicts.  It uses an unusual syntax:
  
@@@ -1339,7 -1338,7 +1339,7 @@@ that part is not conflicting and is no
  
  The diff above shows the differences between the working-tree version of
  file.txt and the stage 2 and stage 3 versions.  So instead of preceding
 -each line by a single "+" or "-", it now uses two columns: the first
 +each line by a single `+` or `-`, it now uses two columns: the first
  column is used for differences between the first parent and the working
  directory copy, and the second for differences between the second parent
  and the working directory copy.  (See the "COMBINED DIFF FORMAT" section
@@@ -1431,7 -1430,7 +1431,7 @@@ parents, one pointing at each of the tw
  were merged.
  
  However, if the current branch is a descendant of the other--so every
 -commit present in the one is already contained in the other--then git
 +commit present in the one is already contained in the other--then Git
  just performs a "fast-forward"; the head of the current branch is moved
  forward to point at the head of the merged-in branch, without any new
  commits being created.
@@@ -1457,7 -1456,7 +1457,7 @@@ fundamentally different ways to fix th
  
  	2. You can go back and modify the old commit.  You should
  	never do this if you have already made the history public;
 -	git does not normally expect the "history" of a project to
 +	Git does not normally expect the "history" of a project to
  	change, and cannot correctly perform repeated merges from
  	a branch that has had its history changed.
  
@@@ -1482,7 -1481,7 +1482,7 @@@ You can also revert an earlier change, 
  $ git revert HEAD^
  -------------------------------------------------
  
 -In this case git will attempt to undo the old change while leaving
 +In this case Git will attempt to undo the old change while leaving
  intact any changes made since then.  If more recent changes overlap
  with the changes to be reverted, then you will be asked to fix
  conflicts manually, just as in the case of <<resolving-a-merge,
@@@ -1581,7 -1580,7 +1581,7 @@@ Ensuring good performanc
  
  On large repositories, Git depends on compression to keep the history
  information from taking up too much space on disk or in memory.  Some
 -git commands may automatically run linkgit:git-gc[1], so you don't
 +Git commands may automatically run linkgit:git-gc[1], so you don't
  have to worry about running it manually.  However, compressing a large
  repository may take a while, so you may want to call `gc` explicitly
  to avoid automatic compression kicking in when it is not convenient.
@@@ -1614,7 -1613,7 +1614,7 @@@ dangling tree b24c2473f1fd3d91352a62479
  
  You will see informational messages on dangling objects. They are objects
  that still exist in the repository but are no longer referenced by any of
 -your branches, and can (and will) be removed after a while with "gc".
 +your branches, and can (and will) be removed after a while with `gc`.
  You can run `git fsck --no-dangling` to suppress these messages, and still
  view real errors.
  
@@@ -1626,11 -1625,11 +1626,11 @@@ Recovering lost change
  Reflogs
  ^^^^^^^
  
 -Say you modify a branch with +linkgit:git-reset[1] \--hard+, and then
 -realize that the branch was the only reference you had to that point in
 -history.
 +Say you modify a branch with <<fixing-mistakes,`git reset --hard`>>,
 +and then realize that the branch was the only reference you had to
 +that point in history.
  
 -Fortunately, git also keeps a log, called a "reflog", of all the
 +Fortunately, Git also keeps a log, called a "reflog", of all the
  previous values of each branch.  So in this case you can still find the
  old history using, for example,
  
@@@ -1639,8 -1638,8 +1639,8 @@@ $ git log master@{1
  -------------------------------------------------
  
  This lists the commits reachable from the previous version of the
 -"master" branch head.  This syntax can be used with any git command
 -that accepts a commit, not just with git log.  Some other examples:
 +`master` branch head.  This syntax can be used with any Git command
 +that accepts a commit, not just with `git log`.  Some other examples:
  
  -------------------------------------------------
  $ git show master@{2}		# See where the branch pointed 2,
@@@ -1665,7 -1664,7 +1665,7 @@@ pruned.  See linkgit:git-reflog[1] and 
  how to control this pruning, and see the "SPECIFYING REVISIONS"
  section of linkgit:gitrevisions[7] for details.
  
 -Note that the reflog history is very different from normal git history.
 +Note that the reflog history is very different from normal Git history.
  While normal history is shared by every repository that works on the
  same project, the reflog history is not shared: it tells you only about
  how the branches in your local repository have changed over time.
@@@ -1744,8 -1743,8 +1744,8 @@@ one step
  $ git pull origin master
  -------------------------------------------------
  
 -In fact, if you have "master" checked out, then this branch has been
 -configured by "git clone" to get changes from the HEAD branch of the
 +In fact, if you have `master` checked out, then this branch has been
 +configured by `git clone` to get changes from the HEAD branch of the
  origin repository.  So often you can
  accomplish the above with just a simple
  
@@@ -1760,11 -1759,11 +1760,11 @@@ the current branch
  More generally, a branch that is created from a remote-tracking branch
  will pull
  by default from that branch.  See the descriptions of the
 -branch.<name>.remote and branch.<name>.merge options in
 +`branch.<name>.remote` and `branch.<name>.merge` options in
  linkgit:git-config[1], and the discussion of the `--track` option in
  linkgit:git-checkout[1], to learn how to control these defaults.
  
 -In addition to saving you keystrokes, "git pull" also helps you by
 +In addition to saving you keystrokes, `git pull` also helps you by
  producing a default commit message documenting the branch and
  repository that you pulled from.
  
@@@ -1772,7 -1771,7 +1772,7 @@@
  <<fast-forwards,fast-forward>>; instead, your branch will just be
  updated to point to the latest commit from the upstream branch.)
  
 -The `git pull` command can also be given "." as the "remote" repository,
 +The `git pull` command can also be given `.` as the "remote" repository,
  in which case it just merges in a branch from the current repository; so
  the commands
  
@@@ -1797,7 -1796,7 +1797,7 @@@ $ git format-patch origi
  -------------------------------------------------
  
  will produce a numbered series of files in the current directory, one
 -for each patch in the current branch but not in origin/HEAD.
 +for each patch in the current branch but not in `origin/HEAD`.
  
  `git format-patch` can include an initial "cover letter". You can insert
  commentary on individual patches after the three dash line which
@@@ -1819,7 -1818,7 +1819,7 @@@ Importing patches to a projec
  Git also provides a tool called linkgit:git-am[1] (am stands for
  "apply mailbox"), for importing such an emailed series of patches.
  Just save all of the patch-containing messages, in order, into a
 -single mailbox file, say "patches.mbox", then run
 +single mailbox file, say `patches.mbox`, then run
  
  -------------------------------------------------
  $ git am -3 patches.mbox
@@@ -1827,8 -1826,8 +1827,8 @@@
  
  Git will apply each patch in order; if any conflicts are found, it
  will stop, and you can fix the conflicts as described in
 -"<<resolving-a-merge,Resolving a merge>>".  (The "-3" option tells
 -git to perform a merge; if you would prefer it just to abort and
 +"<<resolving-a-merge,Resolving a merge>>".  (The `-3` option tells
 +Git to perform a merge; if you would prefer it just to abort and
  leave your tree and index untouched, you may omit that option.)
  
  Once the index is updated with the results of the conflict
@@@ -1838,7 -1837,7 +1838,7 @@@ resolution, instead of creating a new c
  $ git am --resolved
  -------------------------------------------------
  
 -and git will create the commit for you and continue applying the
 +and Git will create the commit for you and continue applying the
  remaining patches from the mailbox.
  
  The final result will be a series of commits, one for each patch in
@@@ -1846,7 -1845,7 +1846,7 @@@ the original mailbox, with authorship a
  taken from the message containing each patch.
  
  [[public-repositories]]
 -Public git repositories
 +Public Git repositories
  -----------------------
  
  Another way to submit changes to a project is to tell the maintainer
@@@ -1903,7 -1902,7 +1903,7 @@@ We explain how to do this in the follow
  Setting up a public repository
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
 -Assume your personal repository is in the directory ~/proj.  We
 +Assume your personal repository is in the directory `~/proj`.  We
  first create a new clone of the repository and tell `git daemon` that it
  is meant to be public:
  
@@@ -1913,28 -1912,28 +1913,28 @@@ $ touch proj.git/git-daemon-export-o
  -------------------------------------------------
  
  The resulting directory proj.git contains a "bare" git repository--it is
 -just the contents of the ".git" directory, without any files checked out
 +just the contents of the `.git` directory, without any files checked out
  around it.
  
 -Next, copy proj.git to the server where you plan to host the
 +Next, copy `proj.git` to the server where you plan to host the
  public repository.  You can use scp, rsync, or whatever is most
  convenient.
  
  [[exporting-via-git]]
 -Exporting a git repository via the git protocol
 +Exporting a Git repository via the Git protocol
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  This is the preferred method.
  
  If someone else administers the server, they should tell you what
 -directory to put the repository in, and what git:// URL it will appear
 -at.  You can then skip to the section
 +directory to put the repository in, and what `git://` URL it will
 +appear at.  You can then skip to the section
  "<<pushing-changes-to-a-public-repository,Pushing changes to a public
  repository>>", below.
  
  Otherwise, all you need to do is start linkgit:git-daemon[1]; it will
  listen on port 9418.  By default, it will allow access to any directory
 -that looks like a git directory and contains the magic file
 +that looks like a Git directory and contains the magic file
  git-daemon-export-ok.  Passing some directory paths as `git daemon`
  arguments will further restrict the exports to those paths.
  
@@@ -1946,10 -1945,10 +1946,10 @@@ examples section.
  Exporting a git repository via HTTP
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
 -The git protocol gives better performance and reliability, but on a
 +The Git protocol gives better performance and reliability, but on a
  host with a web server set up, HTTP exports may be simpler to set up.
  
 -All you need to do is place the newly created bare git repository in
 +All you need to do is place the newly created bare Git repository in
  a directory that is exported by the web server, and make some
  adjustments to give web clients some extra information they need:
  
@@@ -1963,7 -1962,7 +1963,7 @@@ $ mv hooks/post-update.sample hooks/pos
  (For an explanation of the last two lines, see
  linkgit:git-update-server-info[1] and linkgit:githooks[5].)
  
 -Advertise the URL of proj.git.  Anybody else should then be able to
 +Advertise the URL of `proj.git`.  Anybody else should then be able to
  clone or pull from that URL, for example with a command line like:
  
  -------------------------------------------------
@@@ -1986,8 -1985,8 +1986,8 @@@ access, which you will need to update t
  latest changes created in your private repository.
  
  The simplest way to do this is using linkgit:git-push[1] and ssh; to
 -update the remote branch named "master" with the latest state of your
 -branch named "master", run
 +update the remote branch named `master` with the latest state of your
 +branch named `master`, run
  
  -------------------------------------------------
  $ git push ssh://yourserver.com/~you/proj.git master:master
@@@ -2003,7 -2002,7 +2003,7 @@@ As with `git fetch`, `git push` will co
  <<fast-forwards,fast-forward>>; see the following section for details on
  handling this case.
  
 -Note that the target of a "push" is normally a
 +Note that the target of a `push` is normally a
  <<def_bare_repository,bare>> repository.  You can also push to a
  repository that has a checked-out working tree, but a push to update the
  currently checked-out branch is denied by default to prevent confusion.
@@@ -2031,9 -2030,9 +2031,9 @@@ which lets you do the same push with ju
  $ git push public-repo master
  -------------------------------------------------
  
 -See the explanations of the remote.<name>.url, branch.<name>.remote,
 -and remote.<name>.push options in linkgit:git-config[1] for
 -details.
 +See the explanations of the `remote.<name>.url`,
 +`branch.<name>.remote`, and `remote.<name>.push` options in
 +linkgit:git-config[1] for details.
  
  [[forcing-push]]
  What to do when a push fails
@@@ -2098,9 -2097,9 +2098,9 @@@ all push to and pull from a single shar
  linkgit:gitcvs-migration[7] for instructions on how to
  set this up.
  
 -However, while there is nothing wrong with git's support for shared
 +However, while there is nothing wrong with Git's support for shared
  repositories, this mode of operation is not generally recommended,
 -simply because the mode of collaboration that git supports--by
 +simply because the mode of collaboration that Git supports--by
  exchanging patches and pulling from public repositories--has so many
  advantages over the central shared repository:
  
@@@ -2124,8 -2123,8 +2124,8 @@@ Allowing web browsing of a repositor
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  The gitweb cgi script provides users an easy way to browse your
 -project's files and history without having to install git; see the file
 -gitweb/INSTALL in the git source tree for instructions on setting it up.
 +project's files and history without having to install Git; see the file
 +gitweb/INSTALL in the Git source tree for instructions on setting it up.
  
  [[sharing-development-examples]]
  Examples
@@@ -2135,7 -2134,7 +2135,7 @@@
  Maintaining topic branches for a Linux subsystem maintainer
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
 -This describes how Tony Luck uses git in his role as maintainer of the
 +This describes how Tony Luck uses Git in his role as maintainer of the
  IA64 architecture for the Linux kernel.
  
  He uses two public branches:
@@@ -2168,7 -2167,7 +2168,7 @@@ linkgit:git-fetch[1] to keep them up-to
  
  Now create the branches in which you are going to work; these start out
  at the current tip of origin/master branch, and should be set up (using
 -the --track option to linkgit:git-branch[1]) to merge changes in from
 +the `--track` option to linkgit:git-branch[1]) to merge changes in from
  Linus by default.
  
  -------------------------------------------------
@@@ -2185,9 -2184,9 +2185,9 @@@ $ git checkout release && git pul
  
  Important note!  If you have any local changes in these branches, then
  this merge will create a commit object in the history (with no local
 -changes git will simply do a "fast-forward" merge).  Many people dislike
 +changes Git will simply do a "fast-forward" merge).  Many people dislike
  the "noise" that this creates in the Linux history, so you should avoid
 -doing this capriciously in the "release" branch, as these noisy commits
 +doing this capriciously in the `release` branch, as these noisy commits
  will become part of the permanent history when you ask Linus to pull
  from the release branch.
  
@@@ -2229,7 -2228,7 +2229,7 @@@ patches), and create a new branch from 
  Linus's branch. Picking a stable base for your branch will:
  1) help you: by avoiding inclusion of unrelated and perhaps lightly
  tested changes
 -2) help future bug hunters that use "git bisect" to find problems
 +2) help future bug hunters that use `git bisect` to find problems
  
  -------------------------------------------------
  $ git checkout -b speed-up-spinlocks v2.6.35
@@@ -2254,9 -2253,9 +2254,9 @@@ It is unlikely that you would have any 
  spent a while on this step and had also pulled new versions from upstream.
  
  Some time later when enough time has passed and testing done, you can pull the
 -same branch into the "release" tree ready to go upstream.  This is where you
 +same branch into the `release` tree ready to go upstream.  This is where you
  see the value of keeping each patch (or patch series) in its own branch.  It
 -means that the patches can be moved into the "release" tree in any order.
 +means that the patches can be moved into the `release` tree in any order.
  
  -------------------------------------------------
  $ git checkout release && git pull . speed-up-spinlocks
@@@ -2289,7 -2288,7 +2289,7 @@@ If it has been merged, then there will 
  
  Once a patch completes the great cycle (moving from test to release,
  then pulled by Linus, and finally coming back into your local
 -"origin/master" branch), the branch for this change is no longer needed.
 +`origin/master` branch), the branch for this change is no longer needed.
  You detect this when the output from:
  
  -------------------------------------------------
@@@ -2304,8 -2303,8 +2304,8 @@@ $ git branch -d branchnam
  
  Some changes are so trivial that it is not necessary to create a separate
  branch and then merge into each of the test and release branches.  For
 -these changes, just apply directly to the "release" branch, and then
 -merge that into the "test" branch.
 +these changes, just apply directly to the `release` branch, and then
 +merge that into the `test` branch.
  
  After pushing your work to `mytree`, you can use
  linkgit:git-request-pull[1] to prepare a "please pull" request message
@@@ -2320,7 -2319,7 +2320,7 @@@ Here are some of the scripts that simpl
  
  -------------------------------------------------
  ==== update script ====
 -# Update a branch in my GIT tree.  If the branch to be updated
 +# Update a branch in my Git tree.  If the branch to be updated
  # is origin, then pull from kernel.org.  Otherwise merge
  # origin/master branch into test|release branch
  
@@@ -2338,7 -2337,7 +2338,7 @@@ origin
  	fi
  	;;
  *)
 -	echo "Usage: $0 origin|test|release" 1>&2
 +	echo "usage: $0 origin|test|release" 1>&2
  	exit 1
  	;;
  esac
@@@ -2352,7 -2351,7 +2352,7 @@@ pname=$
  
  usage()
  {
 -	echo "Usage: $pname branch test|release" 1>&2
 +	echo "usage: $pname branch test|release" 1>&2
  	exit 1
  }
  
@@@ -2378,7 -2377,7 +2378,7 @@@ esa
  
  -------------------------------------------------
  ==== status script ====
 -# report on status of my ia64 GIT tree
 +# report on status of my ia64 Git tree
  
  gb=$(tput setab 2)
  rb=$(tput setab 1)
@@@ -2434,7 -2433,7 +2434,7 @@@ Rewriting history and maintaining patc
  
  Normally commits are only added to a project, never taken away or
  replaced.  Git is designed with this assumption, and violating it will
 -cause git's merge machinery (for example) to do the wrong thing.
 +cause Git's merge machinery (for example) to do the wrong thing.
  
  However, there is a situation in which it can be useful to violate this
  assumption.
@@@ -2476,8 -2475,8 +2476,8 @@@ you are rewriting history
  Keeping a patch series up to date using git rebase
  --------------------------------------------------
  
 -Suppose that you create a branch "mywork" on a remote-tracking branch
 -"origin", and create some commits on top of it:
 +Suppose that you create a branch `mywork` on a remote-tracking branch
 +`origin`, and create some commits on top of it:
  
  -------------------------------------------------
  $ git checkout -b mywork origin
@@@ -2489,7 -2488,7 +2489,7 @@@ $ git commi
  -------------------------------------------------
  
  You have performed no merges into mywork, so it is just a simple linear
 -sequence of patches on top of "origin":
 +sequence of patches on top of `origin`:
  
  ................................................
   o--o--O <-- origin
@@@ -2498,7 -2497,7 +2498,7 @@@
  ................................................
  
  Some more interesting work has been done in the upstream project, and
 -"origin" has advanced:
 +`origin` has advanced:
  
  ................................................
   o--o--O--o--o--o <-- origin
@@@ -2506,7 -2505,7 +2506,7 @@@
           a--b--c <-- mywork
  ................................................
  
 -At this point, you could use "pull" to merge your changes back in;
 +At this point, you could use `pull` to merge your changes back in;
  the result would create a new merge commit, like this:
  
  ................................................
@@@ -2525,7 -2524,7 +2525,7 @@@ $ git rebase origi
  -------------------------------------------------
  
  This will remove each of your commits from mywork, temporarily saving
 -them as patches (in a directory named ".git/rebase-apply"), update mywork to
 +them as patches (in a directory named `.git/rebase-apply`), update mywork to
  point at the latest version of origin, then apply each of the saved
  patches to the new mywork.  The result will look like:
  
@@@ -2545,7 -2544,7 +2545,7 @@@ running `git commit`, just ru
  $ git rebase --continue
  -------------------------------------------------
  
 -and git will continue applying the rest of the patches.
 +and Git will continue applying the rest of the patches.
  
  At any point you may use the `--abort` option to abort this process and
  return mywork to the state it had before you started the rebase:
@@@ -2702,7 -2701,7 +2702,7 @@@ Git has no way of knowing that the new 
  the old head; it treats this situation exactly the same as it would if
  two developers had independently done the work on the old and new heads
  in parallel.  At this point, if someone attempts to merge the new head
 -in to their branch, git will attempt to merge together the two (old and
 +in to their branch, Git will attempt to merge together the two (old and
  new) lines of development, instead of trying to replace the old by the
  new.  The results are likely to be unexpected.
  
@@@ -2775,7 -2774,7 +2775,7 @@@ linear history
  Bisecting between Z and D* would hit a single culprit commit Y*,
  and understanding why Y* was broken would probably be easier.
  
 -Partly for this reason, many experienced git users, even when
 +Partly for this reason, many experienced Git users, even when
  working on an otherwise merge-heavy project, keep the history
  linear by rebasing against the latest upstream version before
  publishing.
@@@ -2796,10 -2795,10 +2796,10 @@@ arbitrary name
  $ git fetch origin todo:my-todo-work
  -------------------------------------------------
  
 -The first argument, "origin", just tells git to fetch from the
 -repository you originally cloned from.  The second argument tells git
 -to fetch the branch named "todo" from the remote repository, and to
 -store it locally under the name refs/heads/my-todo-work.
 +The first argument, `origin`, just tells Git to fetch from the
 +repository you originally cloned from.  The second argument tells Git
 +to fetch the branch named `todo` from the remote repository, and to
 +store it locally under the name `refs/heads/my-todo-work`.
  
  You can also fetch branches from other repositories; so
  
@@@ -2807,8 -2806,8 +2807,8 @@@
  $ git fetch git://example.com/proj.git master:example-master
  -------------------------------------------------
  
 -will create a new branch named "example-master" and store in it the
 -branch named "master" from the repository at the given URL.  If you
 +will create a new branch named `example-master` and store in it the
 +branch named `master` from the repository at the given URL.  If you
  already have a branch named example-master, it will attempt to
  <<fast-forwards,fast-forward>> to the commit given by example.com's
  master branch.  In more detail:
@@@ -2817,7 -2816,7 +2817,7 @@@
  git fetch and fast-forwards
  ---------------------------
  
 -In the previous example, when updating an existing branch, "git fetch"
 +In the previous example, when updating an existing branch, `git fetch`
  checks to make sure that the most recent commit on the remote
  branch is a descendant of the most recent commit on your copy of the
  branch before updating your copy of the branch to point at the new
@@@ -2843,11 -2842,11 +2843,11 @@@ resulting in a situation like
              o--o--o <-- new head of the branch
  ................................................
  
 -In this case, "git fetch" will fail, and print out a warning.
 +In this case, `git fetch` will fail, and print out a warning.
  
 -In that case, you can still force git to update to the new head, as
 +In that case, you can still force Git to update to the new head, as
  described in the following section.  However, note that in the
 -situation above this may mean losing the commits labeled "a" and "b",
 +situation above this may mean losing the commits labeled `a` and `b`,
  unless you've already created a reference of your own pointing to
  them.
  
@@@ -2862,7 -2861,7 +2862,7 @@@ descendant of the old head, you may for
  $ git fetch git://example.com/proj.git +master:refs/remotes/example/master
  -------------------------------------------------
  
 -Note the addition of the "+" sign.  Alternatively, you can use the "-f"
 +Note the addition of the `+` sign.  Alternatively, you can use the `-f`
  flag to force updates of all the fetched branches, as in:
  
  -------------------------------------------------
@@@ -2876,9 -2875,9 +2876,9 @@@ may be lost, as we saw in the previous 
  Configuring remote-tracking branches
  ------------------------------------
  
 -We saw above that "origin" is just a shortcut to refer to the
 +We saw above that `origin` is just a shortcut to refer to the
  repository that you originally cloned from.  This information is
 -stored in git configuration variables, which you can see using
 +stored in Git configuration variables, which you can see using
  linkgit:git-config[1]:
  
  -------------------------------------------------
@@@ -2930,7 -2929,7 +2930,7 @@@ Git concept
  
  Git is built on a small number of simple but powerful ideas.  While it
  is possible to get things done without understanding them, you will find
 -git much more intuitive if you do.
 +Git much more intuitive if you do.
  
  We start with the most important, the  <<def_object_database,object
  database>> and the <<def_index,index>>.
@@@ -2985,7 -2984,7 +2985,7 @@@ Commit Objec
  ~~~~~~~~~~~~~
  
  The "commit" object links a physical state of a tree with a description
 -of how we got there and why.  Use the --pretty=raw option to
 +of how we got there and why.  Use the `--pretty=raw` option to
  linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
  commit:
  
@@@ -3024,10 -3023,10 +3024,10 @@@ As you can see, a commit is defined by
  Note that a commit does not itself contain any information about what
  actually changed; all changes are calculated by comparing the contents
  of the tree referred to by this commit with the trees associated with
 -its parents.  In particular, git does not attempt to record file renames
 +its parents.  In particular, Git does not attempt to record file renames
  explicitly, though it can identify cases where the existence of the same
  file data at changing paths suggests a rename.  (See, for example, the
 --M option to linkgit:git-diff[1]).
 +`-M` option to linkgit:git-diff[1]).
  
  A commit is usually created by linkgit:git-commit[1], which creates a
  commit whose parent is normally the current HEAD, and whose tree is
@@@ -3063,14 -3062,14 +3063,14 @@@ another tree, representing the content
  and blobs, like all other objects, are named by the SHA-1 hash of their
  contents, two trees have the same SHA-1 name if and only if their
  contents (including, recursively, the contents of all subdirectories)
 -are identical.  This allows git to quickly determine the differences
 +are identical.  This allows Git to quickly determine the differences
  between two related tree objects, since it can ignore any entries with
  identical object names.
  
  (Note: in the presence of submodules, trees may also have commits as
  entries.  See <<submodules>> for documentation.)
  
 -Note that the files all have mode 644 or 755: git actually only pays
 +Note that the files all have mode 644 or 755: Git actually only pays
  attention to the executable bit.
  
  [[blob-object]]
@@@ -3078,7 -3077,7 +3078,7 @@@ Blob Objec
  ~~~~~~~~~~~
  
  You can use linkgit:git-show[1] to examine the contents of a blob; take,
 -for example, the blob in the entry for "COPYING" from the tree above:
 +for example, the blob in the entry for `COPYING` from the tree above:
  
  ------------------------------------------------
  $ git show 6ff87c4664
@@@ -3131,7 -3130,7 +3131,7 @@@ sending out a single email that tells t
  of the top commit, and digitally sign that email using something
  like GPG/PGP.
  
 -To assist in this, git also provides the tag object...
 +To assist in this, Git also provides the tag object...
  
  [[tag-object]]
  Tag Object
@@@ -3161,14 -3160,14 +3161,14 @@@ nLE/L9aUXdWeTFPron96DLA
  See the linkgit:git-tag[1] command to learn how to create and verify tag
  objects.  (Note that linkgit:git-tag[1] can also be used to create
  "lightweight tags", which are not tag objects at all, but just simple
 -references whose names begin with "refs/tags/").
 +references whose names begin with `refs/tags/`).
  
  [[pack-files]]
 -How git stores objects efficiently: pack files
 +How Git stores objects efficiently: pack files
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  Newly created objects are initially created in a file named after the
 -object's SHA-1 hash (stored in .git/objects).
 +object's SHA-1 hash (stored in `.git/objects`).
  
  Unfortunately this system becomes inefficient once a project has a
  lot of objects.  Try this on an old project:
@@@ -3182,7 -3181,7 +3182,7 @@@ The first number is the number of objec
  individual files.  The second is the amount of space taken up by
  those "loose" objects.
  
 -You can save space and make git faster by moving these loose objects in
 +You can save space and make Git faster by moving these loose objects in
  to a "pack file", which stores a group of objects in an efficient
  compressed format; the details of how pack files are formatted can be
  found in link:technical/pack-format.txt[technical/pack-format.txt].
@@@ -3209,9 -3208,9 +3209,9 @@@ $ git prun
  
  to remove any of the "loose" objects that are now contained in the
  pack.  This will also remove any unreferenced objects (which may be
 -created when, for example, you use "git reset" to remove a commit).
 +created when, for example, you use `git reset` to remove a commit).
  You can verify that the loose objects are gone by looking at the
 -.git/objects directory or by running
 +`.git/objects` directory or by running
  
  ------------------------------------------------
  $ git count-objects
@@@ -3238,7 -3237,7 +3238,7 @@@ branch still exists, as does everythin
  pointer itself just doesn't, since you replaced it with another one.
  
  There are also other situations that cause dangling objects. For
 -example, a "dangling blob" may arise because you did a "git add" of a
 +example, a "dangling blob" may arise because you did a `git add` of a
  file, but then, before you actually committed it and made it part of the
  bigger picture, you changed something else in that file and committed
  that *updated* thing--the old state that you added originally ends up
@@@ -3281,14 -3280,14 +3281,14 @@@ $ git show <dangling-blob/tree-sha-goes
  ------------------------------------------------
  
  to show what the contents of the blob were (or, for a tree, basically
 -what the "ls" for that directory was), and that may give you some idea
 +what the `ls` for that directory was), and that may give you some idea
  of what the operation was that left that dangling object.
  
  Usually, dangling blobs and trees aren't very interesting. They're
  almost always the result of either being a half-way mergebase (the blob
  will often even have the conflict markers from a merge in it, if you
  have had conflicting merges that you fixed up by hand), or simply
 -because you interrupted a "git fetch" with ^C or something like that,
 +because you interrupted a `git fetch` with ^C or something like that,
  leaving _some_ of the new objects in the object database, but just
  dangling and useless.
  
@@@ -3299,28 -3298,28 +3299,28 @@@ state, you can just prune all unreachab
  $ git prune
  ------------------------------------------------
  
 -and they'll be gone. But you should only run "git prune" on a quiescent
 +and they'll be gone. But you should only run `git prune` on a quiescent
  repository--it's kind of like doing a filesystem fsck recovery: you
  don't want to do that while the filesystem is mounted.
  
 -(The same is true of "git fsck" itself, btw, but since
 +(The same is true of `git fsck` itself, btw, but since
  `git fsck` never actually *changes* the repository, it just reports
  on what it found, `git fsck` itself is never 'dangerous' to run.
  Running it while somebody is actually changing the repository can cause
  confusing and scary messages, but it won't actually do anything bad. In
 -contrast, running "git prune" while somebody is actively changing the
 +contrast, running `git prune` while somebody is actively changing the
  repository is a *BAD* idea).
  
  [[recovering-from-repository-corruption]]
  Recovering from repository corruption
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
 -By design, git treats data trusted to it with caution.  However, even in
 -the absence of bugs in git itself, it is still possible that hardware or
 +By design, Git treats data trusted to it with caution.  However, even in
 +the absence of bugs in Git itself, it is still possible that hardware or
  operating system errors could corrupt data.
  
  The first defense against such problems is backups.  You can back up a
 -git directory using clone, or just using cp, tar, or any other backup
 +Git directory using clone, or just using cp, tar, or any other backup
  mechanism.
  
  As a last resort, you can search for the corrupted objects and attempt
@@@ -3346,7 -3345,7 +3346,7 @@@ missing blob 4b9458b3786228369c63936db6
  Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
  points to it.  If you could find just one copy of that missing blob
  object, possibly in some other repository, you could move it into
 -.git/objects/4b/9458b3... and be done.  Suppose you can't.  You can
 +`.git/objects/4b/9458b3...` and be done.  Suppose you can't.  You can
  still examine the tree that pointed to it with linkgit:git-ls-tree[1],
  which might output something like:
  
@@@ -3361,10 -3360,10 +3361,10 @@@ $ git ls-tree 2d9263c6d23595e7cb2a21e5e
  ------------------------------------------------
  
  So now you know that the missing blob was the data for a file named
 -"myfile".  And chances are you can also identify the directory--let's
 -say it's in "somedirectory".  If you're lucky the missing copy might be
 +`myfile`.  And chances are you can also identify the directory--let's
 +say it's in `somedirectory`.  If you're lucky the missing copy might be
  the same as the copy you have checked out in your working tree at
 -"somedirectory/myfile"; you can test whether that's right with
 +`somedirectory/myfile`; you can test whether that's right with
  linkgit:git-hash-object[1]:
  
  ------------------------------------------------
@@@ -3419,7 -3418,7 +3419,7 @@@ $ git hash-object -w <recreated-file
  
  and your repository is good again!
  
 -(Btw, you could have ignored the fsck, and started with doing a
 +(Btw, you could have ignored the `fsck`, and started with doing a
  
  ------------------------------------------------
  $ git log --raw --all
@@@ -3433,7 -3432,7 +3433,7 @@@ just missing one particular blob versio
  The index
  -----------
  
 -The index is a binary file (generally kept in .git/index) containing a
 +The index is a binary file (generally kept in `.git/index`) containing a
  sorted list of path names, each with permissions and the SHA-1 of a blob
  object; linkgit:git-ls-files[1] can show you the contents of the index:
  
@@@ -3468,7 -3467,7 +3468,7 @@@ It does this by storing some additiona
  the last modified time).  This data is not displayed above, and is not
  stored in the created tree object, but it can be used to determine
  quickly which files in the working directory differ from what was
 -stored in the index, and thus save git from having to read all of the
 +stored in the index, and thus save Git from having to read all of the
  data from such files to look for changes.
  
  3. It can efficiently represent information about merge conflicts
@@@ -3573,7 -3572,7 +3573,7 @@@ $ ls -
  
  The `git submodule add <repo> <path>` command does a couple of things:
  
 -- It clones the submodule from <repo> to the given <path> under the
 +- It clones the submodule from `<repo>` to the given `<path>` under the
    current directory and by default checks out the master branch.
  - It adds the submodule's clone path to the linkgit:gitmodules[5] file and
    adds this file to the index, ready to be committed.
@@@ -3699,13 -3698,13 +3699,13 @@@ Did you forget to 'git add'
  Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'
  -------------------------------------------------
  
 -In older git versions it could be easily forgotten to commit new or modified
 +In older Git versions it could be easily forgotten to commit new or modified
  files in a submodule, which silently leads to similar problems as not pushing
 -the submodule changes. Starting with git 1.7.0 both "git status" and "git diff"
 +the submodule changes. Starting with Git 1.7.0 both `git status` and `git diff`
  in the superproject show submodules as modified when they contain new or
 -modified files to protect against accidentally committing such a state. "git
 -diff" will also add a "-dirty" to the work tree side when generating patch
 -output or used with the --submodule option:
 +modified files to protect against accidentally committing such a state. `git
 +diff` will also add a `-dirty` to the work tree side when generating patch
 +output or used with the `--submodule` option:
  
  -------------------------------------------------
  $ git diff
@@@ -3746,12 -3745,12 +3746,12 @@@ submodule update` will not overwrite th
  warning about not being able switch from a dirty branch.
  
  [[low-level-operations]]
 -Low-level git operations
 +Low-level Git operations
  ========================
  
  Many of the higher-level commands were originally implemented as shell
 -scripts using a smaller core of low-level git commands.  These can still
 -be useful when doing unusual things with git, or just as a way to
 +scripts using a smaller core of low-level Git commands.  These can still
 +be useful when doing unusual things with Git, or just as a way to
  understand its inner workings.
  
  [[object-manipulation]]
@@@ -3782,7 -3781,7 +3782,7 @@@ between the working tree, the index, an
  provides low-level operations which perform each of these steps
  individually.
  
 -Generally, all "git" operations work on the index file. Some operations
 +Generally, all Git operations work on the index file. Some operations
  work *purely* on the index file (showing the current state of the
  index), but most operations move data between the index file and either
  the database or the working directory. Thus there are four main
@@@ -3805,7 -3804,7 +3805,7 @@@ but to avoid common mistakes with filen
  will not normally add totally new entries or remove old entries,
  i.e. it will normally just update existing cache entries.
  
 -To tell git that yes, you really do realize that certain files no
 +To tell Git that yes, you really do realize that certain files no
  longer exist, or that new files should be added, you
  should use the `--remove` and `--add` flags respectively.
  
@@@ -3881,7 -3880,7 +3881,7 @@@ or, if you want to check out all of th
  
  NOTE! `git checkout-index` normally refuses to overwrite old files, so
  if you have an old version of the tree already checked out, you will
 -need to use the "-f" flag ('before' the "-a" flag or the filename) to
 +need to use the `-f` flag ('before' the `-a` flag or the filename) to
  'force' the checkout.
  
  
@@@ -3892,7 -3891,7 +3892,7 @@@ from one representation to the other
  Tying it all together
  ~~~~~~~~~~~~~~~~~~~~~
  
 -To commit a tree you have instantiated with "git write-tree", you'd
 +To commit a tree you have instantiated with `git write-tree`, you'd
  create a "commit" object that refers to that tree and the history
  behind it--most notably the "parent" commits that preceded it in
  history.
@@@ -3919,7 -3918,7 +3919,7 @@@ redirection from a pipe or file, or by 
  
  `git commit-tree` will return the name of the object that represents
  that commit, and you should save it away for later use. Normally,
 -you'd commit a new `HEAD` state, and while git doesn't care where you
 +you'd commit a new `HEAD` state, and while Git doesn't care where you
  save the note about that state, in practice we tend to just write the
  result to the file pointed at by `.git/HEAD`, so that we can always see
  what the last committed state was.
@@@ -4076,7 -4075,7 +4076,7 @@@ $ git ls-files --unmerge
  
  Each line of the `git ls-files --unmerged` output begins with
  the blob mode bits, blob SHA-1, 'stage number', and the
 -filename.  The 'stage number' is git's way to say which tree it
 +filename.  The 'stage number' is Git's way to say which tree it
  came from: stage 1 corresponds to the `$orig` tree, stage 2 to
  the `HEAD` tree, and stage 3 to the `$target` tree.
  
@@@ -4088,7 -4087,7 +4088,7 @@@ obviously the final outcome is what is 
  above example shows is that file `hello.c` was changed from
  `$orig` to `HEAD` and `$orig` to `$target` in a different way.
  You could resolve this by running your favorite 3-way merge
 -program, e.g.  `diff3`, `merge`, or git's own merge-file, on
 +program, e.g.  `diff3`, `merge`, or Git's own merge-file, on
  the blob objects from these three stages yourself, like this:
  
  ------------------------------------------------
@@@ -4100,7 -4099,7 +4100,7 @@@ $ git merge-file hello.c~2 hello.c~1 he
  
  This would leave the merge result in `hello.c~2` file, along
  with conflict markers if there are conflicts.  After verifying
 -the merge result makes sense, you can tell git what the final
 +the merge result makes sense, you can tell Git what the final
  merge result for this file is by:
  
  -------------------------------------------------
@@@ -4109,11 -4108,11 +4109,11 @@@ $ git update-index hello.
  -------------------------------------------------
  
  When a path is in the "unmerged" state, running `git update-index` for
 -that path tells git to mark the path resolved.
 +that path tells Git to mark the path resolved.
  
 -The above is the description of a git merge at the lowest level,
 +The above is the description of a Git merge at the lowest level,
  to help you understand what conceptually happens under the hood.
 -In practice, nobody, not even git itself, runs `git cat-file` three times
 +In practice, nobody, not even Git itself, runs `git cat-file` three times
  for this.  There is a `git merge-index` program that extracts the
  stages to temporary files and calls a "merge" script on it:
  
@@@ -4124,11 -4123,11 +4124,11 @@@ $ git merge-index git-merge-one-file he
  and that is what higher level `git merge -s resolve` is implemented with.
  
  [[hacking-git]]
 -Hacking git
 +Hacking Git
  ===========
  
 -This chapter covers internal details of the git implementation which
 -probably only git developers need to understand.
 +This chapter covers internal details of the Git implementation which
 +probably only Git developers need to understand.
  
  [[object-details]]
  Object storage format
@@@ -4146,16 -4145,15 +4146,16 @@@ about the data in the object.  It's wor
  that is used to name the object is the hash of the original data
  plus this header, so `sha1sum` 'file' does not match the object name
  for 'file'.
 -(Historical note: in the dawn of the age of git the hash
 +(Historical note: in the dawn of the age of Git the hash
  was the SHA-1 of the 'compressed' object.)
  
  As a result, the general consistency of an object can always be tested
  independently of the contents or the type of the object: all objects can
  be validated by verifying that (a) their hashes match the content of the
  file and (b) the object successfully inflates to a stream of bytes that
 -forms a sequence of <ascii type without space> {plus} <space> {plus} <ascii decimal
 -size> {plus} <byte\0> {plus} <binary object data>.
 +forms a sequence of
 +`<ascii type without space> + <space> + <ascii decimal size> +
 +<byte\0> + <binary object data>`.
  
  The structured objects can further have their structure and
  connectivity to other objects verified. This is generally done with
@@@ -4177,7 -4175,7 +4177,7 @@@ A good place to start is with the conte
  $ git checkout e83c5163
  ----------------------------------------------------
  
 -The initial revision lays the foundation for almost everything git has
 +The initial revision lays the foundation for almost everything Git has
  today, but is small enough to read in one sitting.
  
  Note that terminology has changed since that revision.  For example, the
@@@ -4256,15 -4254,16 +4256,16 @@@ no longer need to call `setup_pager()` 
  Nowadays, `git log` is a builtin, which means that it is _contained_ in the
  command `git`.  The source side of a builtin is
  
- - a function called `cmd_<bla>`, typically defined in `builtin-<bla>.c`,
-   and declared in `builtin.h`,
+ - a function called `cmd_<bla>`, typically defined in `builtin/<bla.c>`
+   (note that older versions of Git used to have it in `builtin-<bla>.c`
+   instead), and declared in `builtin.h`.
  
  - an entry in the `commands[]` array in `git.c`, and
  
  - an entry in `BUILTIN_OBJECTS` in the `Makefile`.
  
  Sometimes, more than one builtin is contained in one source file.  For
- example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin-log.c`,
+ example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin/log.c`,
  since they share quite a bit of code.  In that case, the commands which are
  _not_ named like the `.c` file in which they live have to be listed in
  `BUILT_INS` in the `Makefile`.
@@@ -4287,10 -4286,10 +4288,10 @@@ For the sake of clarity, let's stay wit
  - is plumbing, and
  
  - was around even in the initial commit (it literally went only through
-   some 20 revisions as `cat-file.c`, was renamed to `builtin-cat-file.c`
+   some 20 revisions as `cat-file.c`, was renamed to `builtin/cat-file.c`
    when made a builtin, and then saw less than 10 versions).
  
- So, look into `builtin-cat-file.c`, search for `cmd_cat_file()` and look what
+ So, look into `builtin/cat-file.c`, search for `cmd_cat_file()` and look what
  it does.
  
  ------------------------------------------------------------------
@@@ -4331,7 -4330,7 +4332,7 @@@ Now, for the meat
  This is how you read a blob (actually, not only a blob, but any type of
  object).  To know how the function `read_object_with_reference()` actually
  works, find the source code for it (something like `git grep
 -read_object_with | grep ":[a-z]"` in the git repository), and read
 +read_object_with | grep ":[a-z]"` in the Git repository), and read
  the source.
  
  To find out how the result can be used, just read on in `cmd_cat_file()`:
@@@ -4366,7 -4365,7 +4367,7 @@@ Another example: Find out what to do i
  builtin:
  
  -------------------------------------------------
- $ git log --no-merges --diff-filter=A builtin-*.c
+ $ git log --no-merges --diff-filter=A builtin/*.c
  -------------------------------------------------
  
  You see, Git is actually the best tool to find out about the source of Git
@@@ -4512,7 -4511,7 +4513,7 @@@ $ git bisect bad		# if this revision i
  Making changes
  --------------
  
 -Make sure git knows who to blame:
 +Make sure Git knows who to blame:
  
  ------------------------------------------------
  $ cat >>~/.gitconfig <<\EOF
@@@ -4562,7 -4561,7 +4563,7 @@@ $ git format-patch origin..HEAD # forma
  $ git am mbox # import patches from the mailbox "mbox"
  -----------------------------------------------
  
 -Fetch a branch in a different git repository, then merge into the
 +Fetch a branch in a different Git repository, then merge into the
  current branch:
  
  -----------------------------------------------
@@@ -4623,7 -4622,7 +4624,7 @@@ The basic requirements
  
  - It must be readable in order, from beginning to end, by someone
    intelligent with a basic grasp of the UNIX command line, but without
 -  any special knowledge of git.  If necessary, any other prerequisites
 +  any special knowledge of Git.  If necessary, any other prerequisites
    should be specifically mentioned as they arise.
  - Whenever possible, section headings should clearly describe the task
    they explain how to do, in language that requires no more knowledge
@@@ -4634,10 -4633,10 +4635,10 @@@ Think about how to create a clear chapt
  allow people to get to important topics without necessarily reading
  everything in between.
  
 -Scan Documentation/ for other stuff left out; in particular:
 +Scan `Documentation/` for other stuff left out; in particular:
  
  - howto's
 -- some of technical/?
 +- some of `technical/`?
  - hooks
  - list of commands in linkgit:git[1]
  
diff --combined builtin/help.c
index 062957f629,7854f5a8fa..f1e236b912
--- a/builtin/help.c
+++ b/builtin/help.c
@@@ -1,6 -1,4 +1,4 @@@
  /*
-  * builtin-help.c
-  *
   * Builtin help command
   */
  #include "cache.h"
@@@ -36,12 -34,10 +34,12 @@@ enum help_format 
  static const char *html_path;
  
  static int show_all = 0;
 +static int show_guides = 0;
  static unsigned int colopts;
  static enum help_format help_format = HELP_FORMAT_NONE;
  static struct option builtin_help_options[] = {
 -	OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
 +	OPT_BOOL('a', "all", &show_all, N_("print all available commands")),
 +	OPT_BOOL('g', "guides", &show_guides, N_("print list of useful guides")),
  	OPT_SET_INT('m', "man", &help_format, N_("show man page"), HELP_FORMAT_MAN),
  	OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
  			HELP_FORMAT_WEB),
@@@ -51,7 -47,7 +49,7 @@@
  };
  
  static const char * const builtin_help_usage[] = {
 -	N_("git help [--all] [--man|--web|--info] [command]"),
 +	N_("git help [--all] [--guides] [--man|--web|--info] [command]"),
  	NULL
  };
  
@@@ -238,21 -234,21 +236,21 @@@ static int add_man_viewer_cmd(const cha
  
  static int add_man_viewer_info(const char *var, const char *value)
  {
 -	const char *name = var + 4;
 -	const char *subkey = strrchr(name, '.');
 +	const char *name, *subkey;
 +	int namelen;
  
 -	if (!subkey)
 +	if (parse_config_key(var, "man", &name, &namelen, &subkey) < 0 || !name)
  		return 0;
  
 -	if (!strcmp(subkey, ".path")) {
 +	if (!strcmp(subkey, "path")) {
  		if (!value)
  			return config_error_nonbool(var);
 -		return add_man_viewer_path(name, subkey - name, value);
 +		return add_man_viewer_path(name, namelen, value);
  	}
 -	if (!strcmp(subkey, ".cmd")) {
 +	if (!strcmp(subkey, "cmd")) {
  		if (!value)
  			return config_error_nonbool(var);
 -		return add_man_viewer_cmd(name, subkey - name, value);
 +		return add_man_viewer_cmd(name, namelen, value);
  	}
  
  	return 0;
@@@ -415,37 -411,6 +413,37 @@@ static void show_html_page(const char *
  	open_html(page_path.buf);
  }
  
 +static struct {
 +	const char *name;
 +	const char *help;
 +} common_guides[] = {
 +	{ "attributes", N_("Defining attributes per path") },
 +	{ "glossary", N_("A Git glossary") },
 +	{ "ignore", N_("Specifies intentionally untracked files to ignore") },
 +	{ "modules", N_("Defining submodule properties") },
 +	{ "revisions", N_("Specifying revisions and ranges for Git") },
 +	{ "tutorial", N_("A tutorial introduction to Git (for version 1.5.1 or newer)") },
 +	{ "workflows", N_("An overview of recommended workflows with Git") },
 +};
 +
 +static void list_common_guides_help(void)
 +{
 +	int i, longest = 0;
 +
 +	for (i = 0; i < ARRAY_SIZE(common_guides); i++) {
 +		if (longest < strlen(common_guides[i].name))
 +			longest = strlen(common_guides[i].name);
 +	}
 +
 +	puts(_("The common Git guides are:\n"));
 +	for (i = 0; i < ARRAY_SIZE(common_guides); i++) {
 +		printf("   %s   ", common_guides[i].name);
 +		mput_char(' ', longest - strlen(common_guides[i].name));
 +		puts(_(common_guides[i].help));
 +	}
 +	putchar('\n');
 +}
 +
  int cmd_help(int argc, const char **argv, const char *prefix)
  {
  	int nongit;
@@@ -461,16 -426,7 +459,16 @@@
  		git_config(git_help_config, NULL);
  		printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
  		list_commands(colopts, &main_cmds, &other_cmds);
 +	}
 +
 +	if (show_guides)
 +		list_common_guides_help();
 +
 +	if (show_all || show_guides) {
  		printf("%s\n", _(git_more_info_string));
 +		/*
 +		* We're done. Ignore any remaining args
 +		*/
  		return 0;
  	}
  
diff --combined builtin/notes.c
index 9ed2508f03,ac43cbaeeb..e4100c4982
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@@ -4,7 -4,7 +4,7 @@@
   * Copyright (c) 2010 Johan Herland <johan@herland.net>
   *
   * Based on git-notes.sh by Johannes Schindelin,
-  * and builtin-tag.c by Kristian Høgsberg and Carlos Rica.
+  * and builtin/tag.c by Kristian Høgsberg and Carlos Rica.
   */
  
  #include "cache.h"
@@@ -18,7 -18,9 +18,7 @@@
  #include "parse-options.h"
  #include "string-list.h"
  #include "notes-merge.h"
 -
 -static void commit_notes(struct notes_tree *t, const char *msg);
 -static combine_notes_fn parse_combine_notes_fn(const char *v);
 +#include "notes-utils.h"
  
  static const char * const git_notes_usage[] = {
  	N_("git notes [--ref <notes_ref>] [list [<object>]]"),
@@@ -90,7 -92,10 +90,7 @@@ static const char * const git_notes_get
  };
  
  static const char note_template[] =
 -	"\n"
 -	"#\n"
 -	"# Write/edit the notes for the following object:\n"
 -	"#\n";
 +	"\nWrite/edit the notes for the following object:\n";
  
  struct msg_arg {
  	int given;
@@@ -124,7 -129,7 +124,7 @@@ static void write_commented_object(int 
  		{"show", "--stat", "--no-notes", sha1_to_hex(object), NULL};
  	struct child_process show;
  	struct strbuf buf = STRBUF_INIT;
 -	FILE *show_out;
 +	struct strbuf cbuf = STRBUF_INIT;
  
  	/* Invoke "git show --stat --no-notes $object" */
  	memset(&show, 0, sizeof(show));
@@@ -137,14 -142,21 +137,14 @@@
  		die(_("unable to start 'show' for object '%s'"),
  		    sha1_to_hex(object));
  
 -	/* Open the output as FILE* so strbuf_getline() can be used. */
 -	show_out = xfdopen(show.out, "r");
 -	if (show_out == NULL)
 -		die_errno(_("can't fdopen 'show' output fd"));
 +	if (strbuf_read(&buf, show.out, 0) < 0)
 +		die_errno(_("could not read 'show' output"));
 +	strbuf_add_commented_lines(&cbuf, buf.buf, buf.len);
 +	write_or_die(fd, cbuf.buf, cbuf.len);
  
 -	/* Prepend "# " to each output line and write result to 'fd' */
 -	while (strbuf_getline(&buf, show_out, '\n') != EOF) {
 -		write_or_die(fd, "# ", 2);
 -		write_or_die(fd, buf.buf, buf.len);
 -		write_or_die(fd, "\n", 1);
 -	}
 +	strbuf_release(&cbuf);
  	strbuf_release(&buf);
 -	if (fclose(show_out))
 -		die_errno(_("failed to close pipe to 'show' for object '%s'"),
 -			  sha1_to_hex(object));
 +
  	if (finish_command(&show))
  		die(_("failed to finish 'show' for object '%s'"),
  		    sha1_to_hex(object));
@@@ -158,7 -170,6 +158,7 @@@ static void create_note(const unsigned 
  
  	if (msg->use_editor || !msg->given) {
  		int fd;
 +		struct strbuf buf = STRBUF_INIT;
  
  		/* write the template message before editing: */
  		path = git_pathdup("NOTES_EDITMSG");
@@@ -170,16 -181,11 +170,16 @@@
  			write_or_die(fd, msg->buf.buf, msg->buf.len);
  		else if (prev && !append_only)
  			write_note_data(fd, prev);
 -		write_or_die(fd, note_template, strlen(note_template));
 +
 +		strbuf_addch(&buf, '\n');
 +		strbuf_add_commented_lines(&buf, note_template, strlen(note_template));
 +		strbuf_addch(&buf, '\n');
 +		write_or_die(fd, buf.buf, buf.len);
  
  		write_commented_object(fd, object);
  
  		close(fd);
 +		strbuf_release(&buf);
  		strbuf_reset(&(msg->buf));
  
  		if (launch_editor(path, &(msg->buf), NULL)) {
@@@ -285,13 -291,139 +285,13 @@@ static int parse_reedit_arg(const struc
  	return parse_reuse_arg(opt, arg, unset);
  }
  
 -static void commit_notes(struct notes_tree *t, const char *msg)
 -{
 -	struct strbuf buf = STRBUF_INIT;
 -	unsigned char commit_sha1[20];
 -
 -	if (!t)
 -		t = &default_notes_tree;
 -	if (!t->initialized || !t->ref || !*t->ref)
 -		die(_("Cannot commit uninitialized/unreferenced notes tree"));
 -	if (!t->dirty)
 -		return; /* don't have to commit an unchanged tree */
 -
 -	/* Prepare commit message and reflog message */
 -	strbuf_addstr(&buf, msg);
 -	if (buf.buf[buf.len - 1] != '\n')
 -		strbuf_addch(&buf, '\n'); /* Make sure msg ends with newline */
 -
 -	create_notes_commit(t, NULL, &buf, commit_sha1);
 -	strbuf_insert(&buf, 0, "notes: ", 7); /* commit message starts at index 7 */
 -	update_ref(buf.buf, t->ref, commit_sha1, NULL, 0, DIE_ON_ERR);
 -
 -	strbuf_release(&buf);
 -}
 -
 -static combine_notes_fn parse_combine_notes_fn(const char *v)
 -{
 -	if (!strcasecmp(v, "overwrite"))
 -		return combine_notes_overwrite;
 -	else if (!strcasecmp(v, "ignore"))
 -		return combine_notes_ignore;
 -	else if (!strcasecmp(v, "concatenate"))
 -		return combine_notes_concatenate;
 -	else if (!strcasecmp(v, "cat_sort_uniq"))
 -		return combine_notes_cat_sort_uniq;
 -	else
 -		return NULL;
 -}
 -
 -static int notes_rewrite_config(const char *k, const char *v, void *cb)
 -{
 -	struct notes_rewrite_cfg *c = cb;
 -	if (!prefixcmp(k, "notes.rewrite.") && !strcmp(k+14, c->cmd)) {
 -		c->enabled = git_config_bool(k, v);
 -		return 0;
 -	} else if (!c->mode_from_env && !strcmp(k, "notes.rewritemode")) {
 -		if (!v)
 -			config_error_nonbool(k);
 -		c->combine = parse_combine_notes_fn(v);
 -		if (!c->combine) {
 -			error(_("Bad notes.rewriteMode value: '%s'"), v);
 -			return 1;
 -		}
 -		return 0;
 -	} else if (!c->refs_from_env && !strcmp(k, "notes.rewriteref")) {
 -		/* note that a refs/ prefix is implied in the
 -		 * underlying for_each_glob_ref */
 -		if (!prefixcmp(v, "refs/notes/"))
 -			string_list_add_refs_by_glob(c->refs, v);
 -		else
 -			warning(_("Refusing to rewrite notes in %s"
 -				" (outside of refs/notes/)"), v);
 -		return 0;
 -	}
 -
 -	return 0;
 -}
 -
 -
 -struct notes_rewrite_cfg *init_copy_notes_for_rewrite(const char *cmd)
 -{
 -	struct notes_rewrite_cfg *c = xmalloc(sizeof(struct notes_rewrite_cfg));
 -	const char *rewrite_mode_env = getenv(GIT_NOTES_REWRITE_MODE_ENVIRONMENT);
 -	const char *rewrite_refs_env = getenv(GIT_NOTES_REWRITE_REF_ENVIRONMENT);
 -	c->cmd = cmd;
 -	c->enabled = 1;
 -	c->combine = combine_notes_concatenate;
 -	c->refs = xcalloc(1, sizeof(struct string_list));
 -	c->refs->strdup_strings = 1;
 -	c->refs_from_env = 0;
 -	c->mode_from_env = 0;
 -	if (rewrite_mode_env) {
 -		c->mode_from_env = 1;
 -		c->combine = parse_combine_notes_fn(rewrite_mode_env);
 -		if (!c->combine)
 -			/* TRANSLATORS: The first %s is the name of the
 -			   environment variable, the second %s is its value */
 -			error(_("Bad %s value: '%s'"), GIT_NOTES_REWRITE_MODE_ENVIRONMENT,
 -					rewrite_mode_env);
 -	}
 -	if (rewrite_refs_env) {
 -		c->refs_from_env = 1;
 -		string_list_add_refs_from_colon_sep(c->refs, rewrite_refs_env);
 -	}
 -	git_config(notes_rewrite_config, c);
 -	if (!c->enabled || !c->refs->nr) {
 -		string_list_clear(c->refs, 0);
 -		free(c->refs);
 -		free(c);
 -		return NULL;
 -	}
 -	c->trees = load_notes_trees(c->refs);
 -	string_list_clear(c->refs, 0);
 -	free(c->refs);
 -	return c;
 -}
 -
 -int copy_note_for_rewrite(struct notes_rewrite_cfg *c,
 -			  const unsigned char *from_obj, const unsigned char *to_obj)
 -{
 -	int ret = 0;
 -	int i;
 -	for (i = 0; c->trees[i]; i++)
 -		ret = copy_note(c->trees[i], from_obj, to_obj, 1, c->combine) || ret;
 -	return ret;
 -}
 -
 -void finish_copy_notes_for_rewrite(struct notes_rewrite_cfg *c)
 -{
 -	int i;
 -	for (i = 0; c->trees[i]; i++) {
 -		commit_notes(c->trees[i], "Notes added by 'git notes copy'");
 -		free_notes(c->trees[i]);
 -	}
 -	free(c->trees);
 -	free(c);
 -}
 -
  static int notes_copy_from_stdin(int force, const char *rewrite_cmd)
  {
  	struct strbuf buf = STRBUF_INIT;
  	struct notes_rewrite_cfg *c = NULL;
  	struct notes_tree *t = NULL;
  	int ret = 0;
 +	const char *msg = "Notes added by 'git notes copy'";
  
  	if (rewrite_cmd) {
  		c = init_copy_notes_for_rewrite(rewrite_cmd);
@@@ -333,10 -465,10 +333,10 @@@
  	}
  
  	if (!rewrite_cmd) {
 -		commit_notes(t, "Notes added by 'git notes copy'");
 +		commit_notes(t, msg);
  		free_notes(t);
  	} else {
 -		finish_copy_notes_for_rewrite(c);
 +		finish_copy_notes_for_rewrite(c, msg);
  	}
  	return ret;
  }
diff --combined transport.c
index 359a671c8c,e3b33520cb..e15db9808c
--- a/transport.c
+++ b/transport.c
@@@ -106,8 -106,7 +106,8 @@@ static void insert_packed_refs(const ch
  		return;
  
  	for (;;) {
 -		int cmp = cmp, len;
 +		int cmp = 0; /* assigned before used */
 +		int len;
  
  		if (!fgets(buffer, sizeof(buffer), f)) {
  			fclose(f);
@@@ -508,7 -507,7 +508,7 @@@ static struct ref *get_refs_via_connect
  	struct ref *refs;
  
  	connect_setup(transport, for_push, 0);
 -	get_remote_heads(data->fd[0], &refs,
 +	get_remote_heads(data->fd[0], NULL, 0, &refs,
  			 for_push ? REF_NORMAL : 0, &data->extra_have);
  	data->got_remote_heads = 1;
  
@@@ -519,9 -518,11 +519,9 @@@ static int fetch_refs_via_pack(struct t
  			       int nr_heads, struct ref **to_fetch)
  {
  	struct git_transport_data *data = transport->data;
 -	struct string_list sought = STRING_LIST_INIT_DUP;
  	const struct ref *refs;
  	char *dest = xstrdup(transport->url);
  	struct fetch_pack_args args;
 -	int i;
  	struct ref *refs_tmp = NULL;
  
  	memset(&args, 0, sizeof(args));
@@@ -534,30 -535,29 +534,30 @@@
  	args.quiet = (transport->verbose < 0);
  	args.no_progress = !transport->progress;
  	args.depth = data->options.depth;
 -
 -	for (i = 0; i < nr_heads; i++)
 -		string_list_append(&sought, to_fetch[i]->name);
 +	args.check_self_contained_and_connected =
 +		data->options.check_self_contained_and_connected;
  
  	if (!data->got_remote_heads) {
  		connect_setup(transport, 0, 0);
 -		get_remote_heads(data->fd[0], &refs_tmp, 0, NULL);
 +		get_remote_heads(data->fd[0], NULL, 0, &refs_tmp, 0, NULL);
  		data->got_remote_heads = 1;
  	}
  
  	refs = fetch_pack(&args, data->fd, data->conn,
  			  refs_tmp ? refs_tmp : transport->remote_refs,
 -			  dest, &sought, &transport->pack_lockfile);
 +			  dest, to_fetch, nr_heads,
 +			  &transport->pack_lockfile);
  	close(data->fd[0]);
  	close(data->fd[1]);
  	if (finish_connect(data->conn))
  		refs = NULL;
  	data->conn = NULL;
  	data->got_remote_heads = 0;
 +	data->options.self_contained_and_connected =
 +		args.self_contained_and_connected;
  
  	free_refs(refs_tmp);
  
 -	string_list_clear(&sought, 0);
  	free(dest);
  	return (refs ? 0 : -1);
  }
@@@ -659,7 -659,7 +659,7 @@@ static void print_ok_ref_status(struct 
  		const char *msg;
  
  		strcpy(quickref, status_abbrev(ref->old_sha1));
 -		if (ref->nonfastforward) {
 +		if (ref->forced_update) {
  			strcat(quickref, "...");
  			type = '+';
  			msg = "forced update";
@@@ -695,18 -695,6 +695,18 @@@ static int print_one_push_status(struc
  		print_ref_status('!', "[rejected]", ref, ref->peer_ref,
  						 "non-fast-forward", porcelain);
  		break;
 +	case REF_STATUS_REJECT_ALREADY_EXISTS:
 +		print_ref_status('!', "[rejected]", ref, ref->peer_ref,
 +						 "already exists", porcelain);
 +		break;
 +	case REF_STATUS_REJECT_FETCH_FIRST:
 +		print_ref_status('!', "[rejected]", ref, ref->peer_ref,
 +						 "fetch first", porcelain);
 +		break;
 +	case REF_STATUS_REJECT_NEEDS_FORCE:
 +		print_ref_status('!', "[rejected]", ref, ref->peer_ref,
 +						 "needs force", porcelain);
 +		break;
  	case REF_STATUS_REMOTE_REJECT:
  		print_ref_status('!', "[remote rejected]", ref,
  						 ref->deletion ? NULL : ref->peer_ref,
@@@ -726,7 -714,7 +726,7 @@@
  }
  
  void transport_print_push_status(const char *dest, struct ref *refs,
 -				  int verbose, int porcelain, int *nonfastforward)
 +				  int verbose, int porcelain, unsigned int *reject_reasons)
  {
  	struct ref *ref;
  	int n = 0;
@@@ -745,23 -733,18 +745,23 @@@
  		if (ref->status == REF_STATUS_OK)
  			n += print_one_push_status(ref, dest, n, porcelain);
  
 -	*nonfastforward = 0;
 +	*reject_reasons = 0;
  	for (ref = refs; ref; ref = ref->next) {
  		if (ref->status != REF_STATUS_NONE &&
  		    ref->status != REF_STATUS_UPTODATE &&
  		    ref->status != REF_STATUS_OK)
  			n += print_one_push_status(ref, dest, n, porcelain);
 -		if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD &&
 -		    *nonfastforward != NON_FF_HEAD) {
 +		if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD) {
  			if (head != NULL && !strcmp(head, ref->name))
 -				*nonfastforward = NON_FF_HEAD;
 +				*reject_reasons |= REJECT_NON_FF_HEAD;
  			else
 -				*nonfastforward = NON_FF_OTHER;
 +				*reject_reasons |= REJECT_NON_FF_OTHER;
 +		} else if (ref->status == REF_STATUS_REJECT_ALREADY_EXISTS) {
 +			*reject_reasons |= REJECT_ALREADY_EXISTS;
 +		} else if (ref->status == REF_STATUS_REJECT_FETCH_FIRST) {
 +			*reject_reasons |= REJECT_FETCH_FIRST;
 +		} else if (ref->status == REF_STATUS_REJECT_NEEDS_FORCE) {
 +			*reject_reasons |= REJECT_NEEDS_FORCE;
  		}
  	}
  }
@@@ -799,7 -782,7 +799,7 @@@ static int git_transport_push(struct tr
  		struct ref *tmp_refs;
  		connect_setup(transport, 1, 0);
  
 -		get_remote_heads(data->fd[0], &tmp_refs, REF_NORMAL, NULL);
 +		get_remote_heads(data->fd[0], NULL, 0, &tmp_refs, REF_NORMAL, NULL);
  		data->got_remote_heads = 1;
  	}
  
@@@ -1046,67 -1029,11 +1046,67 @@@ static void die_with_unpushed_submodule
  	die("Aborting.");
  }
  
 +static int run_pre_push_hook(struct transport *transport,
 +			     struct ref *remote_refs)
 +{
 +	int ret = 0, x;
 +	struct ref *r;
 +	struct child_process proc;
 +	struct strbuf buf;
 +	const char *argv[4];
 +
 +	if (!(argv[0] = find_hook("pre-push")))
 +		return 0;
 +
 +	argv[1] = transport->remote->name;
 +	argv[2] = transport->url;
 +	argv[3] = NULL;
 +
 +	memset(&proc, 0, sizeof(proc));
 +	proc.argv = argv;
 +	proc.in = -1;
 +
 +	if (start_command(&proc)) {
 +		finish_command(&proc);
 +		return -1;
 +	}
 +
 +	strbuf_init(&buf, 256);
 +
 +	for (r = remote_refs; r; r = r->next) {
 +		if (!r->peer_ref) continue;
 +		if (r->status == REF_STATUS_REJECT_NONFASTFORWARD) continue;
 +		if (r->status == REF_STATUS_UPTODATE) continue;
 +
 +		strbuf_reset(&buf);
 +		strbuf_addf( &buf, "%s %s %s %s\n",
 +			 r->peer_ref->name, sha1_to_hex(r->new_sha1),
 +			 r->name, sha1_to_hex(r->old_sha1));
 +
 +		if (write_in_full(proc.in, buf.buf, buf.len) != buf.len) {
 +			ret = -1;
 +			break;
 +		}
 +	}
 +
 +	strbuf_release(&buf);
 +
 +	x = close(proc.in);
 +	if (!ret)
 +		ret = x;
 +
 +	x = finish_command(&proc);
 +	if (!ret)
 +		ret = x;
 +
 +	return ret;
 +}
 +
  int transport_push(struct transport *transport,
  		   int refspec_nr, const char **refspec, int flags,
 -		   int *nonfastforward)
 +		   unsigned int *reject_reasons)
  {
 -	*nonfastforward = 0;
 +	*reject_reasons = 0;
  	transport_verify_remote_names(refspec_nr, refspec);
  
  	if (transport->push) {
@@@ -1132,8 -1059,6 +1132,8 @@@
  			match_flags |= MATCH_REFS_MIRROR;
  		if (flags & TRANSPORT_PUSH_PRUNE)
  			match_flags |= MATCH_REFS_PRUNE;
 +		if (flags & TRANSPORT_PUSH_FOLLOW_TAGS)
 +			match_flags |= MATCH_REFS_FOLLOW_TAGS;
  
  		if (match_push_refs(local_refs, &remote_refs,
  				    refspec_nr, refspec, match_flags)) {
@@@ -1144,10 -1069,6 +1144,10 @@@
  			flags & TRANSPORT_PUSH_MIRROR,
  			flags & TRANSPORT_PUSH_FORCE);
  
 +		if (!(flags & TRANSPORT_PUSH_NO_HOOK))
 +			if (run_pre_push_hook(transport, remote_refs))
 +				return -1;
 +
  		if ((flags & TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND) && !is_bare_repository()) {
  			struct ref *ref = remote_refs;
  			for (; ref; ref = ref->next)
@@@ -1178,7 -1099,7 +1178,7 @@@
  		if (!quiet || err)
  			transport_print_push_status(transport->url, remote_refs,
  					verbose | porcelain, porcelain,
 -					nonfastforward);
 +					reject_reasons);
  
  		if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
  			set_upstreams(transport, remote_refs, pretend);
@@@ -1232,7 -1153,7 +1232,7 @@@ int transport_fetch_refs(struct transpo
  		 * then local and remote refs are likely to still be equal.
  		 * Just feed them all to the fetch method in that case.
  		 * This condition shouldn't be met in a non-deepening fetch
- 		 * (see builtin-fetch.c:quickfetch()).
+ 		 * (see builtin/fetch.c:quickfetch()).
  		 */
  		heads = xmalloc(nr_refs * sizeof(*heads));
  		for (rm = refs; rm; rm = rm->next)
diff --combined transport.h
index 4edebc5355,3c03b2858f..ea70ea7e4a
--- a/transport.h
+++ b/transport.h
@@@ -8,8 -8,6 +8,8 @@@ struct git_transport_options 
  	unsigned thin : 1;
  	unsigned keep : 1;
  	unsigned followtags : 1;
 +	unsigned check_self_contained_and_connected : 1;
 +	unsigned self_contained_and_connected : 1;
  	int depth;
  	const char *uploadpack;
  	const char *receivepack;
@@@ -76,7 -74,7 +76,7 @@@ struct transport 
  		       const char *executable, int fd[2]);
  
  	/** get_refs_list(), fetch(), and push_refs() can keep
 -	 * resources (such as a connection) reserved for futher
 +	 * resources (such as a connection) reserved for further
  	 * use. disconnect() releases these resources.
  	 **/
  	int (*disconnect)(struct transport *connection);
@@@ -106,8 -104,6 +106,8 @@@
  #define TRANSPORT_RECURSE_SUBMODULES_CHECK 64
  #define TRANSPORT_PUSH_PRUNE 128
  #define TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND 256
 +#define TRANSPORT_PUSH_NO_HOOK 512
 +#define TRANSPORT_PUSH_FOLLOW_TAGS 1024
  
  #define TRANSPORT_SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3)
  #define TRANSPORT_SUMMARY(x) (int)(TRANSPORT_SUMMARY_WIDTH + strlen(x) - gettext_width(x)), (x)
@@@ -144,15 -140,11 +144,15 @@@ int transport_set_option(struct transpo
  void transport_set_verbosity(struct transport *transport, int verbosity,
  	int force_progress);
  
 -#define NON_FF_HEAD 1
 -#define NON_FF_OTHER 2
 +#define REJECT_NON_FF_HEAD     0x01
 +#define REJECT_NON_FF_OTHER    0x02
 +#define REJECT_ALREADY_EXISTS  0x04
 +#define REJECT_FETCH_FIRST     0x08
 +#define REJECT_NEEDS_FORCE     0x10
 +
  int transport_push(struct transport *connection,
  		   int refspec_nr, const char **refspec, int flags,
 -		   int * nonfastforward);
 +		   unsigned int * reject_reasons);
  
  const struct ref *transport_get_remote_refs(struct transport *transport);
  
@@@ -170,7 -162,7 +170,7 @@@ int transport_connect(struct transport 
  int transport_helper_init(struct transport *transport, const char *name);
  int bidirectional_transfer_loop(int input, int output);
  
- /* common methods used by transport.c and builtin-send-pack.c */
+ /* common methods used by transport.c and builtin/send-pack.c */
  void transport_verify_remote_names(int nr_heads, const char **heads);
  
  void transport_update_tracking_ref(struct remote *remote, struct ref *ref, int verbose);
@@@ -178,7 -170,7 +178,7 @@@
  int transport_refs_pushed(struct ref *ref);
  
  void transport_print_push_status(const char *dest, struct ref *refs,
 -		  int verbose, int porcelain, int *nonfastforward);
 +		  int verbose, int porcelain, unsigned int *reject_reasons);
  
  typedef void alternate_ref_fn(const struct ref *, void *);
  extern void for_each_alternate_ref(alternate_ref_fn, void *);