[v3,2/6] Documentation/git-update-ref.txt: remove safety paragraphs

Commit Message

Kristoffer Haugsbakk Oct. 21, 2024, 8:47 p.m. UTC

From: Kristoffer Haugsbakk <[e-mail]>

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

Evoking the echo strategy is wrong now under the reftable backend since
this file does not exist.  And the ref file backend majority user base
use porcelain commands to manage `HEAD` unless they are intentionally
poking at the implementation.

Maybe this warning was relevant for the usage patterns when it was
added[1] but now it just takes up space.

† 1: 129056370ab (Add missing documentation., 2005-10-04)

Signed-off-by: Kristoffer Haugsbakk <[e-mail]>
---

Notes (series):
    v3:
    • Change commit message: ref backends
    
      Link: https://lore.kernel.org/git/[e-mail]/#t

 Documentation/git-update-ref.txt | 15 ---------------
 1 file changed, 15 deletions(-)

Patch

diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index a2bee2ea24a..1a0aec041ea 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).
-
 With `-d`, it deletes the named <ref> after verifying that it
 still contains <old-oid>.