2005-05-10 23:32:30 +02:00
|
|
|
git-diff-cache(1)
|
|
|
|
=================
|
|
|
|
v0.1, May 2005
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
|
|
|
git-diff-cache - Compares content and mode of blobs between the cache and repository
|
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
2005-06-19 22:14:53 +02:00
|
|
|
'git-diff-cache' [-p] [-r] [-z] [-m] [--cached] [-R] [-B] [-M] [-C] [--find-copies-harder] [-O<orderfile>] [-S<string>] [--pickaxe-all] <tree-ish> [<path>...]
|
2005-05-10 23:32:30 +02:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
2005-05-24 03:20:39 +02:00
|
|
|
Compares the content and mode of the blobs found via a tree
|
|
|
|
object with the content of the current cache and, optionally
|
|
|
|
ignoring the stat state of the file on disk. When paths are
|
|
|
|
specified, compares only those named paths. Otherwise all
|
|
|
|
entries in the cache are compared.
|
2005-05-10 23:32:30 +02:00
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
-------
|
|
|
|
<tree-ish>::
|
|
|
|
The id of a tree object to diff against.
|
|
|
|
|
|
|
|
-p::
|
|
|
|
Generate patch (see section on generating patches)
|
|
|
|
|
|
|
|
-r::
|
|
|
|
This flag does not mean anything. It is there only to match
|
|
|
|
"git-diff-tree". Unlike "git-diff-tree", "git-diff-cache"
|
|
|
|
always looks at all the subdirectories.
|
|
|
|
|
|
|
|
-z::
|
|
|
|
\0 line termination on output
|
|
|
|
|
[PATCH] Add -B flag to diff-* brothers.
A new diffcore transformation, diffcore-break.c, is introduced.
When the -B flag is given, a patch that represents a complete
rewrite is broken into a deletion followed by a creation. This
makes it easier to review such a complete rewrite patch.
The -B flag takes the same syntax as the -M and -C flags to
specify the minimum amount of non-source material the resulting
file needs to have to be considered a complete rewrite, and
defaults to 99% if not specified.
As the new test t4008-diff-break-rewrite.sh demonstrates, if a
file is a complete rewrite, it is broken into a delete/create
pair, which can further be subjected to the usual rename
detection if -M or -C is used. For example, if file0 gets
completely rewritten to make it as if it were rather based on
file1 which itself disappeared, the following happens:
The original change looks like this:
file0 --> file0' (quite different from file0)
file1 --> /dev/null
After diffcore-break runs, it would become this:
file0 --> /dev/null
/dev/null --> file0'
file1 --> /dev/null
Then diffcore-rename matches them up:
file1 --> file0'
The internal score values are finer grained now. Earlier
maximum of 10000 has been raised to 60000; there is no user
visible changes but there is no reason to waste available bits.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-30 09:08:37 +02:00
|
|
|
-B::
|
|
|
|
Break complete rewrite changes into pairs of delete and create.
|
|
|
|
|
2005-05-19 12:32:35 +02:00
|
|
|
-M::
|
2005-05-22 04:42:18 +02:00
|
|
|
Detect renames.
|
2005-05-19 12:32:35 +02:00
|
|
|
|
2005-05-21 11:39:09 +02:00
|
|
|
-C::
|
2005-05-22 04:42:18 +02:00
|
|
|
Detect copies as well as renames.
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2005-06-19 22:14:53 +02:00
|
|
|
--find-copies-harder::
|
|
|
|
By default, -C option finds copies only if the original
|
|
|
|
file of the copy was modified in the same changeset for
|
|
|
|
performance reasons. This flag makes the command
|
|
|
|
inspect unmodified files as candidates for the source of
|
|
|
|
copy. This is a very expensive operation for large
|
|
|
|
projects, so use it with caution.
|
|
|
|
|
2005-05-21 11:40:01 +02:00
|
|
|
-S<string>::
|
|
|
|
Look for differences that contains the change in <string>.
|
|
|
|
|
2005-05-28 11:53:43 +02:00
|
|
|
--pickaxe-all::
|
|
|
|
When -S finds a change, show all the changes in that
|
|
|
|
changeset, not just the files that contains the change
|
|
|
|
in <string>.
|
2005-05-21 11:40:01 +02:00
|
|
|
|
2005-05-30 09:09:07 +02:00
|
|
|
-O<orderfile>::
|
|
|
|
Output the patch in the order specified in the
|
|
|
|
<orderfile>, which has one shell glob pattern per line.
|
|
|
|
|
2005-05-20 04:00:36 +02:00
|
|
|
-R::
|
2005-06-03 10:36:43 +02:00
|
|
|
Swap two inputs; that is, show differences from cache or
|
|
|
|
on-disk file to tree contents.
|
2005-05-20 04:00:36 +02:00
|
|
|
|
2005-05-10 23:32:30 +02:00
|
|
|
--cached::
|
|
|
|
do not consider the on-disk file at all
|
|
|
|
|
|
|
|
-m::
|
|
|
|
By default, files recorded in the index but not checked
|
|
|
|
out are reported as deleted. This flag makes
|
|
|
|
"git-diff-cache" say that all non-checked-out files are up
|
|
|
|
to date.
|
|
|
|
|
|
|
|
Output format
|
|
|
|
-------------
|
|
|
|
include::diff-format.txt[]
|
|
|
|
|
|
|
|
Operating Modes
|
|
|
|
---------------
|
|
|
|
You can choose whether you want to trust the index file entirely
|
|
|
|
(using the '--cached' flag) or ask the diff logic to show any files
|
|
|
|
that don't match the stat state as being "tentatively changed". Both
|
|
|
|
of these operations are very useful indeed.
|
|
|
|
|
|
|
|
Cached Mode
|
|
|
|
-----------
|
|
|
|
If '--cached' is specified, it allows you to ask:
|
|
|
|
|
|
|
|
show me the differences between HEAD and the current index
|
|
|
|
contents (the ones I'd write with a "git-write-tree")
|
|
|
|
|
|
|
|
For example, let's say that you have worked on your index file, 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-cache --cached $(cat .git/HEAD)
|
|
|
|
|
|
|
|
Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
|
|
|
|
done an "git-update-cache" 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-cache" does:
|
|
|
|
|
|
|
|
torvalds@ppc970:~/git> git-diff-cache --cached $(cat .git/HEAD)
|
|
|
|
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
|
|
|
|
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
|
|
|
|
|
|
|
|
You can trivially see that the above is a rename.
|
|
|
|
|
|
|
|
In fact, "git-diff-cache --cached" *should* always be entirely equivalent to
|
|
|
|
actually doing a "git-write-tree" and comparing that. Except this one is much
|
|
|
|
nicer for the case where you just want to check where you are.
|
|
|
|
|
|
|
|
So doing a "git-diff-cache --cached" is basically very useful when you are
|
|
|
|
asking yourself "what have I already marked for being committed, and
|
|
|
|
what's the difference to a previous tree".
|
|
|
|
|
|
|
|
Non-cached Mode
|
|
|
|
---------------
|
|
|
|
The "non-cached" mode takes a different approach, and is potentially
|
|
|
|
the more useful of the two in that what it does can't be emulated with
|
|
|
|
a "git-write-tree" + "git-diff-tree". Thus that's the default mode.
|
|
|
|
The non-cached version asks the question:
|
|
|
|
|
|
|
|
show me the differences between HEAD and the currently checked out
|
|
|
|
tree - index contents _and_ files that aren't up-to-date
|
|
|
|
|
|
|
|
which is obviously a very useful question too, since that tells you what
|
|
|
|
you *could* commit. Again, the output matches the "git-diff-tree -r"
|
|
|
|
output to a tee, but with a twist.
|
|
|
|
|
|
|
|
The twist is that if some file doesn't match the cache, we don't have
|
|
|
|
a backing store thing for it, and we use the magic "all-zero" sha1 to
|
|
|
|
show that. So let's say that you have edited `kernel/sched.c`, but
|
|
|
|
have not actually done a "git-update-cache" on it yet - there is no
|
|
|
|
"object" associated with the new state, and you get:
|
|
|
|
|
|
|
|
torvalds@ppc970:~/v2.6/linux> git-diff-cache $(cat .git/HEAD )
|
|
|
|
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
|
|
|
|
|
|
|
|
ie it shows that the tree has changed, and that `kernel/sched.c` has is
|
|
|
|
not up-to-date and may contain new stuff. The all-zero sha1 means that to
|
|
|
|
get the real diff, you need to look at the object in the working directory
|
|
|
|
directly rather than do an object-to-object diff.
|
|
|
|
|
|
|
|
NOTE! As with other commands of this type, "git-diff-cache" does not
|
|
|
|
actually look at the contents of the file at all. So maybe
|
|
|
|
`kernel/sched.c` hasn't actually changed, and it's just that you
|
|
|
|
touched it. In either case, it's a note that you need to
|
|
|
|
"git-upate-cache" it to make the cache be in sync.
|
|
|
|
|
|
|
|
NOTE 2! You can have a mixture of files show up as "has been updated"
|
|
|
|
and "is still dirty in the working directory" together. You can always
|
|
|
|
tell which file is in which state, since the "has been updated" ones
|
|
|
|
show a valid sha1, and the "not in sync with the index" ones will
|
|
|
|
always have the special all-zero sha1.
|
|
|
|
|
|
|
|
|
|
|
|
Author
|
|
|
|
------
|
|
|
|
Written by Linus Torvalds <torvalds@osdl.org>
|
|
|
|
|
|
|
|
Documentation
|
|
|
|
--------------
|
|
|
|
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
|
|
|
|
|
|
|
|
GIT
|
|
|
|
---
|
|
|
|
Part of the link:git.html[git] suite
|
|
|
|
|