Re: stgit truncates binary files to zero length when applying patches
- From
Karl Hasselström <kha@treskal.com>
- Date
- Nov 16, 2005, 13:03 UTC
- Message-ID
- <20051116130332.GA6744@diana.vm.bytemark.co.uk>
- In-Reply-To
- <b0943d9e0511160431r6c852e5fn@mail.gmail.com>
On 2005-11-16 12:31:27 +0000, Catalin Marinas wrote:
Show 18 quoted lines
> On 16/11/05, Karl Hasselström <kha@treskal.com> wrote: > > > On 2005-11-16 11:11:56 +0000, Catalin Marinas wrote: > > > > > Unfortunately, git-apply doesn't fail for patches including > > > binary files and simply creates an empty file. I think git-apply > > > should be changed to fail to apply this kind of patches. > > > > Yes, at least if stgit is going to continue to use it like this. > > Refusing to handle binary files is somewhat disappointing, but > > still OK; agreeing to handle them and then silently wiping them is > > a bit less OK. > > A workaround for this would be to add a config option for StGIT to > always use the three-way merge for pushing patches. The problem with > this is speed since git-diff-tree | git-apply is much faster (and > pretty safe since fuzzy patching is not allowed) and most of the > patches would apply cleanly with only this.
The proper fix has to be to convince git-apply to either handle patches with binary files, or to make it fail; in both cases, stgit will be fine. If the former is somehow intractable or undesirable, and the latter would break existing callers (and/or inconvenience users), perhaps it could fail on binary files only when a --text-only flag was given.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle