Re: stgit truncates binary files to zero length when applying patches

From: Karl Hasselström <kha@treskal.com>
Date: Nov 16, 2005, 11:54 UTC
Message-ID: <20051116115449.GA5933@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0511160311k725526d8v@mail.gmail.com>

On 2005-11-16 11:11:56 +0000, Catalin Marinas wrote:

Show 6 quoted lines

> On 15/11/05, Karl Hasselström <kha@treskal.com> wrote:
>
> > When applying patches and not fast-forwarding, stgit truncates the
> > binary files to zero length:
>
> I've never tried binaries with StGIT before.

I don't blame you. Binary patches aren't something I normally create either. It's just that I find stgit patches a good way to logically structure a largeish change that I'm working on before committing it. (I could probably accoplish the same thing with one branch instead of each stgit patch, but then it would be quite a lot of work to manually push updates through all the branches.)

Show 8 quoted lines

> When pushing a patch, if a merge is needed (like in your case, the
> base of the foo patch has changed), StGIT first tries "git-diff-tree
> | git-apply" for speed reasons. If this fails, it falls back to a
> three-way merge.
>
> 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. (But don't worry; it is a perfect world, after all, so of course I had backups. :-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle