From: Kristoffer Haugsbakk <code@xxxxxxxxxxxxxxx>
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 <code@xxxxxxxxxxxxxxx>
---
Notes (series):
v3:
• Change commit message: ref backends
Link: https://lore.kernel.org/git/bcb0e2d8-ebee-4835-aa43-05107199ee62@xxxxxxxxxxxxxxxx/#t
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 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>.
--
2.46.1.641.g54e7913fcb6
