diff for deleted file only, when changed to directory

Hi,

when I stage a file deletion (named foo) and than add a new file
(named foo/bar) in a directory with  the name of deleted file. git
diff --cached -- foo shows me the diff for both the file foo and file
foo/bar.

Here is a recipe:

echo foo >f
git add f
git commit -mfoo
git rm f
mkdir f
echo bar >f/0
git add f/0
git diff -- f
git diff --cached -- f

gives me this:

diff --git c/f i/f
deleted file mode 100644
index 257cc56..0000000
--- c/f
+++ /dev/null

@@ -1 +0,0 @@
-foo

diff --git c/f/0 i/f/0
new file mode 100644
index 0000000..5716ca5
--- /dev/null
+++ i/f/0

@@ -0,0 +1 @@
+bar

For the other case, when I stage a symlink under the name foo, I can
understand that git diff shows me two diffs. But for the case
file->directory, I would like to see only the deleted diff, not
recursing into the directory.

Bert

Bert Wesarg wrote:

                                                               git
diff --cached -- foo shows me the diff for both the file foo and file
foo/bar.

[...]

                                             But for the case
file->directory, I would like to see only the deleted diff, not
recursing into the directory.

If I understand correctly, this is a documentation bug and feature
request.

The documentation bug: the "git diff" documentation says something
like

	git diff [--options] [<tree>[..<tree>]] [--] [<path>...]

but the <path>s after "--" are actually patterns (path specifiers).
See [1] ([RFD] git glossary: define pathspec, 2010-11-29).

The feature request: there is no way to specify an "exact match"
or "negative match" when specifying paths.  At least "negative
match" has been suggested before.

[1] http://thread.gmane.org/gmane.comp.version-control.git/162379

2010/12/8 Jonathan Nieder [off-list ref]:

Bert Wesarg wrote:

quoted

                                                               git
diff --cached -- foo shows me the diff for both the file foo and file
foo/bar.

[...]

quoted

                                             But for the case
file->directory, I would like to see only the deleted diff, not
recursing into the directory.

If I understand correctly, this is a documentation bug and feature
request.

The documentation bug: the "git diff" documentation says something
like

       git diff [--options] [<tree>[..<tree>]] [--] [<path>...]

but the <path>s after "--" are actually patterns (path specifiers).
See [1] ([RFD] git glossary: define pathspec, 2010-11-29).

The feature request: there is no way to specify an "exact match"
or "negative match" when specifying paths.  At least "negative
match" has been suggested before.

Thanks for the pointers.

I don't expect that we can change <foo> to match only files and not directories.

Bert

[1] http://thread.gmane.org/gmane.comp.version-control.git/162379

2010/12/8 Bert Wesarg [off-list ref]:

2010/12/8 Jonathan Nieder [off-list ref]:

quoted

Bert Wesarg wrote:

quoted

                                                               git
diff --cached -- foo shows me the diff for both the file foo and file
foo/bar.

[...]

quoted

                                             But for the case
file->directory, I would like to see only the deleted diff, not
recursing into the directory.

If I understand correctly, this is a documentation bug and feature
request.

The documentation bug: the "git diff" documentation says something
like

       git diff [--options] [<tree>[..<tree>]] [--] [<path>...]

but the <path>s after "--" are actually patterns (path specifiers).
See [1] ([RFD] git glossary: define pathspec, 2010-11-29).

The feature request: there is no way to specify an "exact match"
or "negative match" when specifying paths.  At least "negative
match" has been suggested before.

Thanks for the pointers.

I don't expect that we can change <foo> to match only files and not directories.

Try

diff --cached -- '[f]'

From top of my memory, directory matching does not work with
wildcards. By putting wildcards to your patterns, dir should never be
matched again. I haven't tested it though.
-- 
Duy