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