summaryrefslogtreecommitdiff
path: root/t/t4031-diff-rewrite-binary.sh
AgeCommit message (Collapse)AuthorFilesLines
2011-02-22diff: handle diffstat of rewritten binary filesLibravatar Jeff King1-0/+7
The logic in builtin_diffstat assumes that a complete_rewrite pair should have its lines counted. This is nonsensical for binary files and leads to confusing things like: $ git diff --stat --summary HEAD^ HEAD foo.rand | Bin 4096 -> 4096 bytes 1 files changed, 0 insertions(+), 0 deletions(-) $ git diff --stat --summary -B HEAD^ HEAD foo.rand | 34 +++++++++++++++------------------- 1 files changed, 15 insertions(+), 19 deletions(-) rewrite foo.rand (100%) So let's reorder the function to handle binary files first (which from diffstat's perspective look like complete rewrites anyway), then rewrites, then actual diffstats. There are two bonus prizes to this reorder: 1. It gets rid of a now-superfluous goto. 2. The binary case is at the top, which means we can further optimize it in the next patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-05t4030, t4031: work around bogus MSYS bash path conversionLibravatar Johannes Sixt1-1/+1
Recall that MSYS bash converts POSIX style absolute paths to Windows style absolute paths. Unfortunately, it converts a program argument that begins with a double-quote and otherwise looks like an absolute POSIX path, but in doing so, it strips everything past the second double-quote[*]. This case is triggered in the two test scripts. The work-around is to place the Windows style path returned by $(pwd) between the quotes to avoid the path conversion. [*] It is already bogus that a conversion is even considered when a program argument begins with a double-quote because it cannot be an absolute POSIX path. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-05textconv: use shell to run helperLibravatar Jeff King1-1/+1
Currently textconv helpers are run directly. Running through the shell is useful because the user can provide a program with command line arguments, like "antiword -f". It also makes textconv more consistent with other parts of git, most of which run their helpers using the shell. The downside is that textconv helpers with shell metacharacters (like space) in the filename will be broken. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-10Fix t4031Libravatar Junio C Hamano1-1/+1
When I tweaked the patch to use $SHELL_PATH instead of a hard-coded "#!/bin/sh" to produce 3aa1f7c (diff: respect textconv in rewrite diffs, 2008-12-09), I screwed up. This should fix it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-09diff: respect textconv in rewrite diffsLibravatar Jeff King1-1/+23
Currently we just skip rewrite diffs for binary files; this patch makes an exception for files which will be textconv'd, and actually performs the textconv before generating the diff. Conceptually, rewrite diffs should be in the exact same format as the a non-rewrite diff, except that we refuse to share any context. Thus it makes very little sense for "git diff" to show a textconv'd diff, but for "git diff -B" to show "Binary files differ". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-09diff: fix handling of binary rewrite diffsLibravatar Jeff King1-0/+45
The current emit_rewrite_diff code always writes a text patch without checking whether the content is binary. This means that if you end up with a rewrite diff for a binary file, you get lots of raw binary goo in your patch. Instead, if we have binary files, then let's just skip emit_rewrite_diff altogether. We will already have shown the "dissimilarity index" line, so it is really about the diff contents. If binary diffs are turned off, the "Binary files a/file and b/file differ" message should be the same in either case. If we do have binary patches turned on, there isn't much point in making a less-efficient binary patch that does a total rewrite; no human is going to read it, and since binary patches don't apply with any fuzz anyway, the result of application should be the same. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>