Documentation: do not blindly run 'cat' .git/HEAD, or echo into it.

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>
This commit is contained in:
Junio C Hamano 2005-11-15 01:31:04 -08:00
parent 313c4714c5
commit cd0a781c38
7 changed files with 14 additions and 13 deletions

View 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:
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

View 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
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
-------

View 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
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:
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
@ -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:
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

View File

@ -68,7 +68,7 @@ that aren't readable from any of the specified head nodes.
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

View 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:
$ 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

View 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
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).

6
README
View File

@ -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
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.
@ -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
git-cat-file commit $(cat .git/HEAD)
git-cat-file commit HEAD
to see what the top commit was.