From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 1 Apr 2013 16:19:04 +0000 (-0700)
Subject: Merge branch 'da/downcase-u-in-usage' into maint
X-Git-Tag: v1.8.2.1~24
X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/41e603af58c3814d06e1c2b5d1449d516007a255?hp=-c

Merge branch 'da/downcase-u-in-usage' into maint

* da/downcase-u-in-usage:
contrib/mw-to-git/t/install-wiki.sh: use a lowercase "usage:" string
contrib/examples/git-remote.perl: use a lowercase "usage:" string
tests: use a lowercase "usage:" string
git-svn: use a lowercase "usage:" string
Documentation/user-manual.txt: use a lowercase "usage:" string
templates/hooks--update.sample: use a lowercase "usage:" string
contrib/hooks/setgitperms.perl: use a lowercase "usage:" string
contrib/examples: use a lowercase "usage:" string
contrib/fast-import/import-zips.py: use spaces instead of tabs
contrib/fast-import/import-zips.py: fix broken error message
contrib/fast-import: use a lowercase "usage:" string
contrib/credential: use a lowercase "usage:" string
git-cvsimport: use a lowercase "usage:" string
git-cvsimport: use a lowercase "usage:" string
git-cvsexportcommit: use a lowercase "usage:" string
git-archimport: use a lowercase "usage:" string
git-merge-one-file: use a lowercase "usage:" string
git-relink: use a lowercase "usage:" string
git-svn: use a lowercase "usage:" string
git-sh-setup: use a lowercase "usage:" string
---

41e603af58c3814d06e1c2b5d1449d516007a255
diff --combined Documentation/user-manual.txt
index 0170a2346c,d290632d18..e831cc2020
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@@ -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
@@@ -66,11 -66,11 +66,11 @@@ $ git clone git://git.kernel.org/pub/sc
  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]]
@@@ -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
@@@ -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
  	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,7 -374,7 +374,7 @@@ 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
@@@ -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]).
@@@ -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:
  
  -------------------------------------------------
@@@ -462,7 -462,7 +462,7 @@@ $ 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
 +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.)
  
@@@ -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,
@@@ -545,11 -545,11 +545,11 @@@ 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:
  
  -------------------------------------------------
@@@ -561,8 -561,8 +561,8 @@@ bad one between some first skipped comm
  
  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,7 -681,7 +681,7 @@@ 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
@@@ -742,8 -742,8 +742,8 @@@ Example
  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:
  
  -------------------------------------------------
@@@ -1062,7 -1062,7 +1062,7 @@@ at step 3, Git maintains a snapshot of 
  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.
  
@@@ -1172,9 -1172,8 +1172,9 @@@ annoying to have these untracked files 
  `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
@@@ -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
@@@ -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,9 -1625,9 +1626,9 @@@ 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
  previous values of each branch.  So in this case you can still find the
@@@ -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,
@@@ -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,7 -1826,7 +1827,7 @@@
  
  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
 +"<<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.)
  
@@@ -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,10 -1912,10 +1913,10 @@@ $ 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.
  
@@@ -1927,8 -1926,8 +1927,8 @@@ Exporting a Git repository via the Git 
  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.
  
@@@ -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,11 -2002,11 +2003,11 @@@ 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.
 -See the description ofthe receive.denyCurrentBranch option
 +See the description of the receive.denyCurrentBranch option
  in linkgit:git-config[1] for details.
  
  As with `git fetch`, you may also set up configuration options to
@@@ -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
@@@ -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.
  
  -------------------------------------------------
@@@ -2187,7 -2186,7 +2187,7 @@@ Important note!  If you have any local 
  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
  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,16 -2303,20 +2304,16 @@@ $ 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.
  
 -To create diffstat and shortlog summaries of changes to include in a "please
 -pull" request to Linus you can use:
 +After pushing your work to `mytree`, you can use
 +linkgit:git-request-pull[1] to prepare a "please pull" request message
 +to send to Linus:
  
  -------------------------------------------------
 -$ git diff --stat origin..release
 --------------------------------------------------
 -
 -and
 -
 --------------------------------------------------
 -$ git log -p origin..release | git shortlog
 +$ git push mytree
 +$ git request-pull origin mytree release
  -------------------------------------------------
  
  Here are some of the scripts that simplify all this even further.
@@@ -2338,7 -2341,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 -2355,7 +2352,7 @@@ pname=$
  
  usage()
  {
- 	echo "Usage: $pname branch test|release" 1>&2
+ 	echo "usage: $pname branch test|release" 1>&2
  	exit 1
  }
  
@@@ -2476,8 -2479,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 -2492,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 -2501,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 -2509,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 -2528,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:
  
@@@ -2554,12 -2557,6 +2554,12 @@@ return mywork to the state it had befor
  $ git rebase --abort
  -------------------------------------------------
  
 +If you need to reorder or edit a number of commits in a branch, it may
 +be easier to use `git rebase -i`, which allows you to reorder and
 +squash commits, as well as marking them for individual editing during
 +the rebase.  See <<interactive-rebase>> for details, and
 +<<reordering-patch-series>> for alternatives.
 +
  [[rewriting-one-commit]]
  Rewriting a single commit
  -------------------------
@@@ -2573,89 -2570,72 +2573,89 @@@ $ git commit --amen
  
  which will replace the old commit by a new commit incorporating your
  changes, giving you a chance to edit the old commit message first.
 +This is useful for fixing typos in your last commit, or for adjusting
 +the patch contents of a poorly staged commit.
  
 -You can also use a combination of this and linkgit:git-rebase[1] to
 -replace a commit further back in your history and recreate the
 -intervening changes on top of it.  First, tag the problematic commit
 -with
 +If you need to amend commits from deeper in your history, you can
 +use <<interactive-rebase,interactive rebase's `edit` instruction>>.
  
 --------------------------------------------------
 -$ git tag bad mywork~5
 --------------------------------------------------
 -
 -(Either gitk or `git log` may be useful for finding the commit.)
 +[[reordering-patch-series]]
 +Reordering or selecting from a patch series
 +-------------------------------------------
  
 -Then check out that commit, edit it, and rebase the rest of the series
 -on top of it (note that we could check out the commit on a temporary
 -branch, but instead we're using a <<detached-head,detached head>>):
 +Sometimes you want to edit a commit deeper in your history.  One
 +approach is to use `git format-patch` to create a series of patches
 +and then reset the state to before the patches:
  
  -------------------------------------------------
 -$ git checkout bad
 -$ # make changes here and update the index
 -$ git commit --amend
 -$ git rebase --onto HEAD bad mywork
 +$ git format-patch origin
 +$ git reset --hard origin
  -------------------------------------------------
  
 -When you're done, you'll be left with mywork checked out, with the top
 -patches on mywork reapplied on top of your modified commit.  You can
 -then clean up with
 +Then modify, reorder, or eliminate patches as needed before applying
 +them again with linkgit:git-am[1]:
  
  -------------------------------------------------
 -$ git tag -d bad
 +$ git am *.patch
  -------------------------------------------------
  
 -Note that the immutable nature of Git history means that you haven't really
 -"modified" existing commits; instead, you have replaced the old commits with
 -new commits having new object names.
 +[[interactive-rebase]]
 +Using interactive rebases
 +-------------------------
  
 -[[reordering-patch-series]]
 -Reordering or selecting from a patch series
 --------------------------------------------
 +You can also edit a patch series with an interactive rebase.  This is
 +the same as <<reordering-patch-series,reordering a patch series using
 +`format-patch`>>, so use whichever interface you like best.
  
 -Given one existing commit, the linkgit:git-cherry-pick[1] command
 -allows you to apply the change introduced by that commit and create a
 -new commit that records it.  So, for example, if "mywork" points to a
 -series of patches on top of "origin", you might do something like:
 +Rebase your current HEAD on the last commit you want to retain as-is.
 +For example, if you want to reorder the last 5 commits, use:
  
  -------------------------------------------------
 -$ git checkout -b mywork-new origin
 -$ gitk origin..mywork &
 +$ git rebase -i HEAD~5
  -------------------------------------------------
  
 -and browse through the list of patches in the mywork branch using gitk,
 -applying them (possibly in a different order) to mywork-new using
 -cherry-pick, and possibly modifying them as you go using `git commit --amend`.
 -The linkgit:git-gui[1] command may also help as it allows you to
 -individually select diff hunks for inclusion in the index (by
 -right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
 -
 -Another technique is to use `git format-patch` to create a series of
 -patches, then reset the state to before the patches:
 +This will open your editor with a list of steps to be taken to perform
 +your rebase.
  
  -------------------------------------------------
 -$ git format-patch origin
 -$ git reset --hard origin
 --------------------------------------------------
 +pick deadbee The oneline of this commit
 +pick fa1afe1 The oneline of the next commit
 +...
  
 -Then modify, reorder, or eliminate patches as preferred before applying
 -them again with linkgit:git-am[1].
 +# Rebase c0ffeee..deadbee onto c0ffeee
 +#
 +# Commands:
 +#  p, pick = use commit
 +#  r, reword = use commit, but edit the commit message
 +#  e, edit = use commit, but stop for amending
 +#  s, squash = use commit, but meld into previous commit
 +#  f, fixup = like "squash", but discard this commit's log message
 +#  x, exec = run command (the rest of the line) using shell
 +#
 +# These lines can be re-ordered; they are executed from top to bottom.
 +#
 +# If you remove a line here THAT COMMIT WILL BE LOST.
 +#
 +# However, if you remove everything, the rebase will be aborted.
 +#
 +# Note that empty commits are commented out
 +-------------------------------------------------
 +
 +As explained in the comments, you can reorder commits, squash them
 +together, edit commit messages, etc. by editing the list.  Once you
 +are satisfied, save the list and close your editor, and the rebase
 +will begin.
 +
 +The rebase will stop where `pick` has been replaced with `edit` or
 +when a step in the list fails to mechanically resolve conflicts and
 +needs your help.  When you are done editing and/or resolving conflicts
 +you can continue with `git rebase --continue`.  If you decide that
 +things are getting too hairy, you can always bail out with `git rebase
 +--abort`.  Even after the rebase is complete, you can still recover
 +the original branch by using the <<reflogs,reflog>>.
 +
 +For a more detailed discussion of the procedure and additional tips,
 +see the "INTERACTIVE MODE" section of linkgit:git-rebase[1].
  
  [[patch-series-tools]]
  Other tools
@@@ -2796,10 -2776,10 +2796,10 @@@ arbitrary name
  $ git fetch origin todo:my-todo-work
  -------------------------------------------------
  
 -The first argument, "origin", just tells Git to fetch from the
 +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.
 +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 -2787,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 -2797,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 -2823,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
  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 -2842,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,7 -2856,7 +2876,7 @@@ 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
  linkgit:git-config[1]:
@@@ -2985,7 -2965,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:
  
@@@ -3027,7 -3007,7 +3027,7 @@@ of the tree referred to by this commit 
  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
@@@ -3078,7 -3058,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
@@@ -3161,14 -3141,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
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  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:
@@@ -3209,9 -3189,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 -3218,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 -3261,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,16 -3279,16 +3299,16 @@@ 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]]
@@@ -3346,7 -3326,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 -3341,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 -3399,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 -3413,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:
  
@@@ -3573,7 -3553,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.
@@@ -3701,11 -3681,11 +3701,11 @@@ Unable to checkout '261dfac35cb99d380eb
  
  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
@@@ -3741,9 -3721,7 +3741,9 @@@ module 
  
  NOTE: The changes are still visible in the submodule's reflog.
  
 -This is not the case if you did not commit your changes.
 +If you have uncommitted changes in your submodule working tree, `git
 +submodule update` will not overwrite them.  Instead, you get the usual
 +warning about not being able switch from a dirty branch.
  
  [[low-level-operations]]
  Low-level Git operations
@@@ -3881,7 -3859,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 -3870,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.
@@@ -4153,9 -4131,8 +4153,9 @@@ As a result, the general consistency o
  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
@@@ -4634,10 -4611,10 +4634,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 contrib/credential/wincred/git-credential-wincred.c
index dac19eac81,66194929fc..a1d38f035b
--- a/contrib/credential/wincred/git-credential-wincred.c
+++ b/contrib/credential/wincred/git-credential-wincred.c
@@@ -9,8 -9,6 +9,8 @@@
  
  /* common helpers */
  
 +#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
 +
  static void die(const char *err, ...)
  {
  	char msg[4096];
@@@ -32,6 -30,14 +32,6 @@@ static void *xmalloc(size_t size
  	return ret;
  }
  
 -static char *xstrdup(const char *str)
 -{
 -	char *ret = strdup(str);
 -	if (!ret)
 -		die("Out of memory");
 -	return ret;
 -}
 -
  /* MinGW doesn't have wincred.h, so we need to define stuff */
  
  typedef struct _CREDENTIAL_ATTRIBUTEW {
@@@ -61,14 -67,20 +61,14 @@@ typedef struct _CREDENTIALW 
  #define CRED_MAX_ATTRIBUTES 64
  
  typedef BOOL (WINAPI *CredWriteWT)(PCREDENTIALW, DWORD);
 -typedef BOOL (WINAPI *CredUnPackAuthenticationBufferWT)(DWORD, PVOID, DWORD,
 -    LPWSTR, DWORD *, LPWSTR, DWORD *, LPWSTR, DWORD *);
  typedef BOOL (WINAPI *CredEnumerateWT)(LPCWSTR, DWORD, DWORD *,
      PCREDENTIALW **);
 -typedef BOOL (WINAPI *CredPackAuthenticationBufferWT)(DWORD, LPWSTR, LPWSTR,
 -    PBYTE, DWORD *);
  typedef VOID (WINAPI *CredFreeT)(PVOID);
  typedef BOOL (WINAPI *CredDeleteWT)(LPCWSTR, DWORD, DWORD);
  
 -static HMODULE advapi, credui;
 +static HMODULE advapi;
  static CredWriteWT CredWriteW;
 -static CredUnPackAuthenticationBufferWT CredUnPackAuthenticationBufferW;
  static CredEnumerateWT CredEnumerateW;
 -static CredPackAuthenticationBufferWT CredPackAuthenticationBufferW;
  static CredFreeT CredFree;
  static CredDeleteWT CredDeleteW;
  
@@@ -76,84 -88,74 +76,84 @@@ static void load_cred_funcs(void
  {
  	/* load DLLs */
  	advapi = LoadLibrary("advapi32.dll");
 -	credui = LoadLibrary("credui.dll");
 -	if (!advapi || !credui)
 -		die("failed to load DLLs");
 +	if (!advapi)
 +		die("failed to load advapi32.dll");
  
  	/* get function pointers */
  	CredWriteW = (CredWriteWT)GetProcAddress(advapi, "CredWriteW");
 -	CredUnPackAuthenticationBufferW = (CredUnPackAuthenticationBufferWT)
 -	    GetProcAddress(credui, "CredUnPackAuthenticationBufferW");
  	CredEnumerateW = (CredEnumerateWT)GetProcAddress(advapi,
  	    "CredEnumerateW");
 -	CredPackAuthenticationBufferW = (CredPackAuthenticationBufferWT)
 -	    GetProcAddress(credui, "CredPackAuthenticationBufferW");
  	CredFree = (CredFreeT)GetProcAddress(advapi, "CredFree");
  	CredDeleteW = (CredDeleteWT)GetProcAddress(advapi, "CredDeleteW");
 -	if (!CredWriteW || !CredUnPackAuthenticationBufferW ||
 -	    !CredEnumerateW || !CredPackAuthenticationBufferW || !CredFree ||
 -	    !CredDeleteW)
 +	if (!CredWriteW || !CredEnumerateW || !CredFree || !CredDeleteW)
  		die("failed to load functions");
  }
  
 -static char target_buf[1024];
 -static char *protocol, *host, *path, *username;
 -static WCHAR *wusername, *password, *target;
 +static WCHAR *wusername, *password, *protocol, *host, *path, target[1024];
  
 -static void write_item(const char *what, WCHAR *wbuf)
 +static void write_item(const char *what, LPCWSTR wbuf, int wlen)
  {
  	char *buf;
 -	int len = WideCharToMultiByte(CP_UTF8, 0, wbuf, -1, NULL, 0, NULL,
 +	int len = WideCharToMultiByte(CP_UTF8, 0, wbuf, wlen, NULL, 0, NULL,
  	    FALSE);
  	buf = xmalloc(len);
  
 -	if (!WideCharToMultiByte(CP_UTF8, 0, wbuf, -1, buf, len, NULL, FALSE))
 +	if (!WideCharToMultiByte(CP_UTF8, 0, wbuf, wlen, buf, len, NULL, FALSE))
  		die("WideCharToMultiByte failed!");
  
  	printf("%s=", what);
 -	fwrite(buf, 1, len - 1, stdout);
 +	fwrite(buf, 1, len, stdout);
  	putchar('\n');
  	free(buf);
  }
  
 -static int match_attr(const CREDENTIALW *cred, const WCHAR *keyword,
 -    const char *want)
 +/*
 + * Match an (optional) expected string and a delimiter in the target string,
 + * consuming the matched text by updating the target pointer.
 + */
 +static int match_part(LPCWSTR *ptarget, LPCWSTR want, LPCWSTR delim)
  {
 -	int i;
 -	if (!want)
 -		return 1;
 -
 -	for (i = 0; i < cred->AttributeCount; ++i)
 -		if (!wcscmp(cred->Attributes[i].Keyword, keyword))
 -			return !strcmp((const char *)cred->Attributes[i].Value,
 -			    want);
 -
 -	return 0; /* not found */
 +	LPCWSTR delim_pos, start = *ptarget;
 +	int len;
 +
 +	/* find start of delimiter (or end-of-string if delim is empty) */
 +	if (*delim)
 +		delim_pos = wcsstr(start, delim);
 +	else
 +		delim_pos = start + wcslen(start);
 +
 +	/*
 +	 * match text up to delimiter, or end of string (e.g. the '/' after
 +	 * host is optional if not followed by a path)
 +	 */
 +	if (delim_pos)
 +		len = delim_pos - start;
 +	else
 +		len = wcslen(start);
 +
 +	/* update ptarget if we either found a delimiter or need a match */
 +	if (delim_pos || want)
 +		*ptarget = delim_pos ? delim_pos + wcslen(delim) : start + len;
 +
 +	return !want || (!wcsncmp(want, start, len) && !want[len]);
  }
  
  static int match_cred(const CREDENTIALW *cred)
  {
 -	return (!wusername || !wcscmp(wusername, cred->UserName)) &&
 -	    match_attr(cred, L"git_protocol", protocol) &&
 -	    match_attr(cred, L"git_host", host) &&
 -	    match_attr(cred, L"git_path", path);
 +	LPCWSTR target = cred->TargetName;
 +	if (wusername && wcscmp(wusername, cred->UserName))
 +		return 0;
 +
 +	return match_part(&target, L"git", L":") &&
 +		match_part(&target, protocol, L"://") &&
 +		match_part(&target, wusername, L"@") &&
 +		match_part(&target, host, L"/") &&
 +		match_part(&target, path, L"");
  }
  
  static void get_credential(void)
  {
 -	WCHAR *user_buf, *pass_buf;
 -	DWORD user_buf_size = 0, pass_buf_size = 0;
 -	CREDENTIALW **creds, *cred = NULL;
 +	CREDENTIALW **creds;
  	DWORD num_creds;
  	int i;
  
@@@ -163,36 -165,90 +163,36 @@@
  	/* search for the first credential that matches username */
  	for (i = 0; i < num_creds; ++i)
  		if (match_cred(creds[i])) {
 -			cred = creds[i];
 +			write_item("username", creds[i]->UserName,
 +				wcslen(creds[i]->UserName));
 +			write_item("password",
 +				(LPCWSTR)creds[i]->CredentialBlob,
 +				creds[i]->CredentialBlobSize / sizeof(WCHAR));
  			break;
  		}
 -	if (!cred)
 -		return;
 -
 -	CredUnPackAuthenticationBufferW(0, cred->CredentialBlob,
 -	    cred->CredentialBlobSize, NULL, &user_buf_size, NULL, NULL,
 -	    NULL, &pass_buf_size);
 -
 -	user_buf = xmalloc(user_buf_size * sizeof(WCHAR));
 -	pass_buf = xmalloc(pass_buf_size * sizeof(WCHAR));
 -
 -	if (!CredUnPackAuthenticationBufferW(0, cred->CredentialBlob,
 -	    cred->CredentialBlobSize, user_buf, &user_buf_size, NULL, NULL,
 -	    pass_buf, &pass_buf_size))
 -		die("CredUnPackAuthenticationBuffer failed");
  
  	CredFree(creds);
 -
 -	/* zero-terminate (sizes include zero-termination) */
 -	user_buf[user_buf_size - 1] = L'\0';
 -	pass_buf[pass_buf_size - 1] = L'\0';
 -
 -	write_item("username", user_buf);
 -	write_item("password", pass_buf);
 -
 -	free(user_buf);
 -	free(pass_buf);
 -}
 -
 -static void write_attr(CREDENTIAL_ATTRIBUTEW *attr, const WCHAR *keyword,
 -    const char *value)
 -{
 -	attr->Keyword = (LPWSTR)keyword;
 -	attr->Flags = 0;
 -	attr->ValueSize = strlen(value) + 1; /* store zero-termination */
 -	attr->Value = (LPBYTE)value;
  }
  
  static void store_credential(void)
  {
  	CREDENTIALW cred;
 -	BYTE *auth_buf;
 -	DWORD auth_buf_size = 0;
 -	CREDENTIAL_ATTRIBUTEW attrs[CRED_MAX_ATTRIBUTES];
  
  	if (!wusername || !password)
  		return;
  
 -	/* query buffer size */
 -	CredPackAuthenticationBufferW(0, wusername, password,
 -	    NULL, &auth_buf_size);
 -
 -	auth_buf = xmalloc(auth_buf_size);
 -
 -	if (!CredPackAuthenticationBufferW(0, wusername, password,
 -	    auth_buf, &auth_buf_size))
 -		die("CredPackAuthenticationBuffer failed");
 -
  	cred.Flags = 0;
  	cred.Type = CRED_TYPE_GENERIC;
  	cred.TargetName = target;
  	cred.Comment = L"saved by git-credential-wincred";
 -	cred.CredentialBlobSize = auth_buf_size;
 -	cred.CredentialBlob = auth_buf;
 +	cred.CredentialBlobSize = (wcslen(password)) * sizeof(WCHAR);
 +	cred.CredentialBlob = (LPVOID)password;
  	cred.Persist = CRED_PERSIST_LOCAL_MACHINE;
 -	cred.AttributeCount = 1;
 -	cred.Attributes = attrs;
 +	cred.AttributeCount = 0;
 +	cred.Attributes = NULL;
  	cred.TargetAlias = NULL;
  	cred.UserName = wusername;
  
 -	write_attr(attrs, L"git_protocol", protocol);
 -
 -	if (host) {
 -		write_attr(attrs + cred.AttributeCount, L"git_host", host);
 -		cred.AttributeCount++;
 -	}
 -
 -	if (path) {
 -		write_attr(attrs + cred.AttributeCount, L"git_path", path);
 -		cred.AttributeCount++;
 -	}
 -
  	if (!CredWriteW(&cred, 0))
  		die("CredWrite failed");
  }
@@@ -228,13 -284,10 +228,13 @@@ static void read_credential(void
  
  	while (fgets(buf, sizeof(buf), stdin)) {
  		char *v;
 +		int len = strlen(buf);
 +		/* strip trailing CR / LF */
 +		while (len && strchr("\r\n", buf[len - 1]))
 +			buf[--len] = 0;
  
 -		if (!strcmp(buf, "\n"))
 +		if (!*buf)
  			break;
 -		buf[strlen(buf)-1] = '\0';
  
  		v = strchr(buf, '=');
  		if (!v)
@@@ -242,12 -295,13 +242,12 @@@
  		*v++ = '\0';
  
  		if (!strcmp(buf, "protocol"))
 -			protocol = xstrdup(v);
 +			protocol = utf8_to_utf16_dup(v);
  		else if (!strcmp(buf, "host"))
 -			host = xstrdup(v);
 +			host = utf8_to_utf16_dup(v);
  		else if (!strcmp(buf, "path"))
 -			path = xstrdup(v);
 +			path = utf8_to_utf16_dup(v);
  		else if (!strcmp(buf, "username")) {
 -			username = xstrdup(v);
  			wusername = utf8_to_utf16_dup(v);
  		} else if (!strcmp(buf, "password"))
  			password = utf8_to_utf16_dup(v);
@@@ -259,7 -313,7 +259,7 @@@
  int main(int argc, char *argv[])
  {
  	const char *usage =
- 	    "Usage: git credential-wincred <get|store|erase>\n";
+ 	    "usage: git credential-wincred <get|store|erase>\n";
  
  	if (!argv[1])
  		die(usage);
@@@ -276,20 -330,22 +276,20 @@@
  		return 0;
  
  	/* prepare 'target', the unique key for the credential */
 -	strncat(target_buf, "git:", sizeof(target_buf));
 -	strncat(target_buf, protocol, sizeof(target_buf));
 -	strncat(target_buf, "://", sizeof(target_buf));
 -	if (username) {
 -		strncat(target_buf, username, sizeof(target_buf));
 -		strncat(target_buf, "@", sizeof(target_buf));
 +	wcscpy(target, L"git:");
 +	wcsncat(target, protocol, ARRAY_SIZE(target));
 +	wcsncat(target, L"://", ARRAY_SIZE(target));
 +	if (wusername) {
 +		wcsncat(target, wusername, ARRAY_SIZE(target));
 +		wcsncat(target, L"@", ARRAY_SIZE(target));
  	}
  	if (host)
 -		strncat(target_buf, host, sizeof(target_buf));
 +		wcsncat(target, host, ARRAY_SIZE(target));
  	if (path) {
 -		strncat(target_buf, "/", sizeof(target_buf));
 -		strncat(target_buf, path, sizeof(target_buf));
 +		wcsncat(target, L"/", ARRAY_SIZE(target));
 +		wcsncat(target, path, ARRAY_SIZE(target));
  	}
  
 -	target = utf8_to_utf16_dup(target_buf);
 -
  	if (!strcmp(argv[1], "get"))
  		get_credential();
  	else if (!strcmp(argv[1], "store"))