From: Kristoffer Haugsbakk <redacted>

Remove paragraphs which explain that using this command is safer than
echoing the branch name into `HEAD`.

These paragraphs have been part of the documentation since the
documentation was created in 129056370ab (Add missing documentation.,
2005-10-04), back when the command synopsis was a lot simpler:

    `git-update-ref` <ref> <newvalue> [<oldvalue>]

These paragraphs don’t interrupt the flow of the document on that
revision since it is at the end.  Now though it is placed after the
description of `--no-deref` and before `-d` and `--stdin`.  Covering all
the options is more generally interesting than a safety note about a
naïve `HEAD` management.

Such a safety warning is also much less relevant now, considering that
everyone who isn’t intentionally poking at the internal implementation
is using porcelain commands to manage `HEAD`.

Signed-off-by: Kristoffer Haugsbakk <redacted>
---
 Documentation/git-update-ref.txt | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index fe5967234e9..ec268b1426d 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt

@@ -40,21 +40,6 @@ somewhere else with a regular filename).
 If --no-deref is given, <ref> itself is overwritten, rather than
 the result of following the symbolic pointers.

-In general, using
-
-	git update-ref HEAD "$head"
-
-should be a _lot_ safer than doing
-
-	echo "$head" > "$GIT_DIR/HEAD"
-
-both from a symlink following standpoint *and* an error checking
-standpoint.  The "refs/" rule for symlinks means that symlinks
-that point to "outside" the tree are safe: they'll be followed
-for reading but not for writing (so we'll never write through a
-ref symlink to some other tree, if you have copied a whole
-archive by creating a symlink tree).
-