]> git.ipfire.org Git - thirdparty/git.git/commit - diff.c
fix bogus "diff --git" header from "diff --no-index"
authorLinus Torvalds <torvalds@linux-foundation.org>
Sun, 5 Oct 2008 19:35:15 +0000 (15:35 -0400)
committerShawn O. Pearce <spearce@spearce.org>
Mon, 6 Oct 2008 07:29:28 +0000 (00:29 -0700)
commit71b989e7dd1dcf891369319cfeda0ed8b6a152e1
tree3ef93a4e58dab604e8e9024dba48c6297af7313d
parentfe8aa148b2cba66fb2643e4df1670c132da5d706
fix bogus "diff --git" header from "diff --no-index"

When "git diff --no-index" is given an absolute pathname, it
would generate a diff header with the absolute path
prepended by the prefix, like:

  diff --git a/dev/null b/foo

Not only is this nonsensical, and not only does it violate
the description of diffs given in git-diff(1), but it would
produce broken binary diffs. Unlike text diffs, the binary
diffs don't contain the filenames anywhere else, and so "git
apply" relies on this header to figure out the filename.

This patch just refuses to use an invalid name for anything
visible in the diff.

Now, this fixes the "git diff --no-index --binary a
/dev/null" kind of case (and we'll end up using "a" as the
basename), but some other insane cases are impossible to
handle. If you do

git diff --no-index --binary a /bin/echo

you'll still get a patch like

diff --git a/a b/bin/echo
old mode 100644
new mode 100755
index ...

and "git apply" will refuse to apply it for a couple of
reasons, and the diff is simply bogus.

And that, btw, is no longer a bug, I think. It's impossible
to know whethe the user meant for the patch to be a rename
or not. And as such, refusing to apply it because you don't
know what name you should use is probably _exactly_ the
right thing to do!

Original problem reported by Imre Deak. Test script and problem
description by Jeff King.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
diff.c
t/t4012-diff-binary.sh