Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> writes:
> This patch uses git-apply to do the patching which simplifies the code a lot.
>
> Removed the test for checking for matching binary files when deleting them
> since git-apply happily deletes the file. This is matter of taste since we
> allow some fuzz for text patches also.
>
> Error handling was cleaned up, but not much tested.
Interesting.
I think you should be able to generate the patchfile once, and
use git-apply to figure out additions, deletions and binaryness,
and then use the same patchfile to apply the changes. Currently
checking for binaryness is not easy with git-apply, so we would
want to fix git-apply first, instead of forcing you to have a
change like this:
# the --binary format is harder to grok for names of binary
# files so we execute a new diff
# if it looks like binary files exists to find out
if (grep /^GIT binary patch$/, @diff) {
@binfiles = grep m/^Binary files/,
safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);
which is way too ugly.
... goes to look and comes back, with a big grin ...
Well, have you tried this?
git diff-tree -p --binary fe142b3a | git apply --summary --numstat
The numstat part would let you see the binaryness, so we do not
have to "fix" git-apply.
Another thing that _might_ be interesting is to use rename
detection when preparing the patch, and make the matching rename
on the CVS side, but I do not recall the details of how one
would make CVS pretend to support renamed paths ;-). I think it
involved copying the ,v file to a new name, and marking the
older revisions in that new ,v file as nonexistent or something
like that, but I did it only in my distant past and forgot the
details.
By the way, I am not sure if giving fuzz by default is such a
good idea, though.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html