From 744c282cd4f92a6c9942131189f2dc722e3a1a2a Mon Sep 17 00:00:00 2001 From: Kristoffer Haugsbakk Date: Mon, 21 Oct 2024 22:47:25 +0200 Subject: [PATCH] Documentation/git-update-ref.txt: remove safety paragraphs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Signed-off-by: Taylor Blau --- 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 a2bee2ea24..1a0aec041e 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, 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 after verifying that it still contains .