Merge branch 'maint'

* maint:
  checkout: allow detaching to HEAD even when switching to the tip of a branch
  Updated documentation of hooks in git-receive-pack.
  Allow fetching references from any namespace
  tiny fix in documentation of git-clone
  Fix an unmatched comment end in arm/sha1_arm.S

Author: Junio C Hamano

Documentation/git-clone.txt

@@ -132,7 +132,7 @@ Make a local clone that borrows from the current directory, without checking thi
 +
 ------------
 $ git clone -l -s -n . ../copy
-$ cd copy
+$ cd ../copy
 $ git show-branch
 ------------
 

Documentation/hooks.txt

@@ -90,6 +90,35 @@ parameter, and is invoked after a commit is made.
 This hook is meant primarily for notification, and cannot affect
 the outcome of `git-commit`.
 
+[[pre-receive]]
+pre-receive
+-----------
+
+This hook is invoked by `git-receive-pack` on the remote repository,
+which happens when a `git push` is done on a local repository.
+Just before starting to update refs on the remote repository, the
+pre-receive hook is invoked.  Its exit status determines the success
+or failure of the update.
+
+This hook executes once for the receive operation. It takes no
+arguments, but for each ref to be updated it receives on standard
+input a line of the format:
+
+  <old-value> SP <new-value> SP <ref-name> LF
+
+where `<old-value>` is the old object name stored in the ref,
+`<new-value>` is the new object name to be stored in the ref and
+`<ref-name>` is the full name of the ref.
+When creating a new ref, `<old-value>` is 40 `0`.
+
+If the hook exits with non-zero status, none of the refs will be
+updated. If the hook exits with zero, updating of individual refs can
+still be prevented by the <<update,'update'>> hook.
+
+If you want to report something to the `git-send-pack` on the other end,
+you can simply `echo` your messages.
+
+[[update]]
 update
 ------
 
@@ -108,7 +137,7 @@ three parameters:
 
 A zero exit from the update hook allows the ref to be updated.
 Exiting with a non-zero status prevents `git-receive-pack`
-from updating the ref.
+from updating that ref.
 
 This hook can be used to prevent 'forced' update on certain refs by
 making sure that the object name is a commit object that is a
@@ -117,7 +146,8 @@ That is, to enforce a "fast forward only" policy.
 
 It could also be used to log the old..new status.  However, it
 does not know the entire set of branches, so it would end up
-firing one e-mail per ref when used naively, though.
+firing one e-mail per ref when used naively, though.  The
+<<post-receive,'post-receive'>> hook is more suited to that.
 
 Another use suggested on the mailing list is to use this hook to
 implement access control which is finer grained than the one
@@ -127,9 +157,38 @@ The standard output of this hook is sent to `stderr`, so if you
 want to report something to the `git-send-pack` on the other end,
 you can simply `echo` your messages.
 
-The default 'update' hook, when enabled, demonstrates how to
-send out a notification e-mail.
+The default 'update' hook, when enabled--and with
+`hooks.allowunannotated` config option turned on--prevents
+unannotated tags to be pushed.
+
+[[post-receive]]
+post-receive
+------------
 
+This hook is invoked by `git-receive-pack` on the remote repository,
+which happens when a `git push` is done on a local repository.
+It executes on the remote repository once after all the refs have
+been updated.
+
+This hook executes once for the receive operation.  It takes no
+arguments, but gets the same information as the `pre-receive`
+hook does on its standard input.
+
+This hook does not affect the outcome of `git-receive-pack`, as it
+is called after the real work is done.
+
+This supersedes the [[post-update]] hook in that it actually get's
+both old and new values of all the refs.
+
+If you want to report something to the `git-send-pack` on the
+other end, you can simply `echo` your messages.
+
+The default 'post-receive' hook is empty, but there is
+a sample script `post-receive-email` provided in the `contrib/hooks`
+directory in git distribution, which implements sending commit
+emails.
+
+[[post-update]]
 post-update
 -----------
 
@@ -148,12 +207,16 @@ The 'post-update' hook can tell what are the heads that were pushed,
 but it does not know what their original and updated values are,
 so it is a poor place to do log old..new.
 
+In general, `post-receive` hook is preferred when the hook needs
+to decide its acion on the status of the entire set of refs
+being updated, as this hook is called once per ref, with
+information only on a single ref at a time.
+
 When enabled, the default 'post-update' hook runs
 `git-update-server-info` to keep the information used by dumb
 transports (e.g., HTTP) up-to-date.  If you are publishing
 a git repository that is accessible via HTTP, you should
 probably enable this hook.
 
-The standard output of this hook is sent to `/dev/null`; if you
-want to report something to the `git-send-pack` on the other end,
-you can redirect your output to your `stderr`.
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end.

arm/sha1_arm.S

@@ -23,7 +23,7 @@ sha_transform:
 	stmfd	sp!, {r4 - r8, lr}
 
 	@ for (i = 0; i < 16; i++)
-	@         W[i] = ntohl(((uint32_t *)data)[i]); */
+	@         W[i] = ntohl(((uint32_t *)data)[i]);
 
 #ifdef __ARMEB__
 	mov	r4, r0

git-parse-remote.sh

@@ -143,13 +143,13 @@ canon_refs_list_for_fetch () {
 		fi
 		case "$remote" in
 		'' | HEAD ) remote=HEAD ;;
-		refs/heads/* | refs/tags/* | refs/remotes/*) ;;
+		refs/*) ;;
 		heads/* | tags/* | remotes/* ) remote="refs/$remote" ;;
 		*) remote="refs/heads/$remote" ;;
 		esac
 		case "$local" in
 		'') local= ;;
-		refs/heads/* | refs/tags/* | refs/remotes/*) ;;
+		refs/*) ;;
 		heads/* | tags/* | remotes/* ) local="refs/$local" ;;
 		*) local="refs/heads/$local" ;;
 		esac