Documentation: do not blindly run 'cat' .git/HEAD, or echo into it.
authorJunio C Hamano <junkio@cox.net>
Tue, 15 Nov 2005 09:31:04 +0000 (01:31 -0800)
committerJunio C Hamano <junkio@cox.net>
Tue, 15 Nov 2005 09:31:04 +0000 (01:31 -0800)
Many places in the documentation we still talked about reading
what commit is recorded in .git/HEAD or writing the new head
information into it, both assuming .git/HEAD is a symlink. That
is not necessarily so.

Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/diff-format.txt
Documentation/git-commit-tree.txt
Documentation/git-diff-index.txt
Documentation/git-fsck-objects.txt
Documentation/git-read-tree.txt
Documentation/git-symbolic-ref.txt
README
index b426a14f5e5fa29bfdb8f026d995dc182930073d..97756ec03086614051d5780b00825e24ee5ef56f 100644 (file)
@@ -81,7 +81,7 @@ The "diff" formatting options can be customized via the
 environment variable 'GIT_DIFF_OPTS'.  For example, if you
 prefer context diff:
 
 environment variable 'GIT_DIFF_OPTS'.  For example, if you
 prefer context diff:
 
-      GIT_DIFF_OPTS=-c git-diff-index -p $(cat .git/HEAD)
+      GIT_DIFF_OPTS=-c git-diff-index -p HEAD
 
 
 2. When the environment variable 'GIT_EXTERNAL_DIFF' is set, the
 
 
 2. When the environment variable 'GIT_EXTERNAL_DIFF' is set, the
index 5cf6bd3e211f6b5d4b53821e2a88b91cc6d80070..a794192d7b50438a2a04aaad816b57dd38f79272 100644 (file)
@@ -26,8 +26,9 @@ to get there.
 
 Normally a commit would identify a new "HEAD" state, and while git
 doesn't care where you save the note about that state, in practice we
 
 Normally a commit would identify a new "HEAD" state, and while git
 doesn't care where you save the note about that state, in practice we
-tend to just write the result to the file `.git/HEAD`, so that we can
-always see what the last committed state was.
+tend to just write the result to the file that is pointed at by
+`.git/HEAD`, so that we can always see what the last committed
+state was.
 
 OPTIONS
 -------
 
 OPTIONS
 -------
index d8fc78fab94d73fe32808cbfaaf4fcfc3efe9694..dba6d30fcf6c0200b8e60c989dacca7ca21af75d 100644 (file)
@@ -57,14 +57,14 @@ some files in the index and are ready to commit. You want to see eactly
 *what* you are going to commit is without having to write a new tree
 object and compare it that way, and to do that, you just do
 
 *what* you are going to commit is without having to write a new tree
 object and compare it that way, and to do that, you just do
 
-       git-diff-index --cached $(cat .git/HEAD)
+       git-diff-index --cached HEAD
 
 Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
 done an "git-update-index" to make that effective in the index file.
 "git-diff-files" wouldn't show anything at all, since the index file
 matches my working directory. But doing a "git-diff-index" does:
 
 
 Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
 done an "git-update-index" to make that effective in the index file.
 "git-diff-files" wouldn't show anything at all, since the index file
 matches my working directory. But doing a "git-diff-index" does:
 
-  torvalds@ppc970:~/git> git-diff-index --cached $(cat .git/HEAD)
+  torvalds@ppc970:~/git> git-diff-index --cached HEAD
   -100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        commit.c
   +100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        git-commit.c
 
   -100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        commit.c
   +100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        git-commit.c
 
@@ -98,7 +98,7 @@ show that. So let's say that you have edited `kernel/sched.c`, but
 have not actually done a "git-update-index" on it yet - there is no
 "object" associated with the new state, and you get:
 
 have not actually done a "git-update-index" on it yet - there is no
 "object" associated with the new state, and you get:
 
-  torvalds@ppc970:~/v2.6/linux> git-diff-index $(cat .git/HEAD )
+  torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
   *100644->100664 blob    7476bb......->000000......      kernel/sched.c
 
 ie it shows that the tree has changed, and that `kernel/sched.c` has is
   *100644->100664 blob    7476bb......->000000......      kernel/sched.c
 
 ie it shows that the tree has changed, and that `kernel/sched.c` has is
index 37e8055d2141a6893991201c628bc07549c04b27..bab1f6080c462cc32ff85551fef3d925fa88ef16 100644 (file)
@@ -68,7 +68,7 @@ that aren't readable from any of the specified head nodes.
 
 So for example
 
 
 So for example
 
-       git-fsck-objects --unreachable $(cat .git/HEAD .git/refs/heads/*)
+       git-fsck-objects --unreachable HEAD $(cat .git/refs/heads/*)
 
 will do quite a _lot_ of verification on the tree. There are a few
 extra validity tests to be added (make sure that tree objects are
 
 will do quite a _lot_ of verification on the tree. There are a few
 extra validity tests to be added (make sure that tree objects are
index 7be0cbd620b37e0b3f2dcd09372e7934ed85223c..8b91847856b51fbe6727ad96e6d5e4d1fd00c815 100644 (file)
@@ -237,7 +237,7 @@ This is done to prevent you from losing your work-in-progress
 changes.  To illustrate, suppose you start from what has been
 commited last to your repository:
 
 changes.  To illustrate, suppose you start from what has been
 commited last to your repository:
 
-    $ JC=`cat .git/HEAD`
+    $ JC=`git-rev-parse --verify "HEAD^0"`
     $ git-checkout-index -f -u -a $JC
 
 You do random edits, without running git-update-index.  And then
     $ git-checkout-index -f -u -a $JC
 
 You do random edits, without running git-update-index.  And then
index a851ae24c4eb079eedec0b889baddf9911820c19..68ac6a65df304adf99f0af95698ffc901dda873c 100644 (file)
@@ -24,8 +24,8 @@ Traditionally, `.git/HEAD` is a symlink pointing at
 we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we want
 to find out which branch we are on, we did `readlink .git/HEAD`.
 This was fine, and internally that is what still happens by
 we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we want
 to find out which branch we are on, we did `readlink .git/HEAD`.
 This was fine, and internally that is what still happens by
-default, but on platforms that does not have working symlinks,
-or that does not have the `readlink(1)` command, this was a bit
+default, but on platforms that do not have working symlinks,
+or that do not have the `readlink(1)` command, this was a bit
 cumbersome.  On some platforms, `ln -sf` does not even work as
 advertised (horrors).
 
 cumbersome.  On some platforms, `ln -sf` does not even work as
 advertised (horrors).
 
diff --git a/README b/README
index 4a2616ba570728320f0b2cf8d7e80df32cbba603..36fef6ec041cd1d0d31c79a98f23a84e9a8691fd 100644 (file)
--- a/README
+++ b/README
@@ -396,8 +396,8 @@ git-commit-tree will return the name of the object that represents
 that commit, and you should save it away for later use. Normally,
 you'd commit a new `HEAD` state, and while git doesn't care where you
 save the note about that state, in practice we tend to just write the
 that commit, and you should save it away for later use. Normally,
 you'd commit a new `HEAD` state, and while git doesn't care where you
 save the note about that state, in practice we tend to just write the
-result to the file `.git/HEAD`, so that we can always see what the
-last committed state was.
+result to the file pointed at by `.git/HEAD`, so that we can always see
+what the last committed state was.
 
 Here is an ASCII art by Jon Loeliger that illustrates how
 various pieces fit together.
 
 Here is an ASCII art by Jon Loeliger that illustrates how
 various pieces fit together.
@@ -464,7 +464,7 @@ tend to be small and fairly self-explanatory. In particular, if you
 follow the convention of having the top commit name in `.git/HEAD`,
 you can do
 
 follow the convention of having the top commit name in `.git/HEAD`,
 you can do
 
-               git-cat-file commit $(cat .git/HEAD)
+               git-cat-file commit HEAD
 
 to see what the top commit was.
 
 
 to see what the top commit was.