Why is there a --binary option needed for git-apply?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I was recently emailed a patch that introduced some new binary files
to my repository. The patch included a very pleasant-looking chunk
along the lines of:

	diff --git a/new/file.png b/new/file.png
	new file mode 100644
	index 0000000000000000000000000000000000000000..e7edd8141e15f5753ea94244e7315bd1341a8c05
	GIT binary patch

I tried applying the patch with git-apply (1.4.2.rc2.gef1d9) and
received an inscrutable error:

	fatal: patch with only garbage at line 90

Where line 90 happened to be the line after the first chunk.

I was disappointed that the operation had failed and started guessing
at problem causes (git version incompatibilities? MUA whitespace
munging?).

Shawn Pearce was kind enough to direct me to the --binary option for
git-apply which solved my problem. But that left me wondering why
git-apply requires this extra command-line option to do its
job. Shouldn't git-apply simply apply the patch it is given?

If there is some reason for git-apply to only apply binary patches
when under the duress of --binary, then at the very least it could use
a better error message explaining the situation.

-Carl
--
cworth@xxxxxxxxxx

Attachment: pgpzcYCFgjrqS.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]