Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934704AbcJXTmR (ORCPT ); Mon, 24 Oct 2016 15:42:17 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:35414 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933009AbcJXTmO (ORCPT ); Mon, 24 Oct 2016 15:42:14 -0400 MIME-Version: 1.0 In-Reply-To: <20161024182503.GH42084@redhat.com> References: <20161024182503.GH42084@redhat.com> From: Linus Torvalds Date: Mon, 24 Oct 2016 12:24:31 -0700 X-Google-Sender-Auth: SYUbg_wweeWSKNoq349XUw49pPQ Message-ID: Subject: Re: Linux-4.X-rcY patches can't be applied with git? To: Jarod Wilson Cc: Linux Kernel Mailing List , Greg Kroah-Hartman Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2576 Lines: 63 On Mon, Oct 24, 2016 at 11:25 AM, Jarod Wilson wrote: > It's entirely possible that we (Red Hat and the Fedora kernel team) are > doing something wrong here, but to the best of our knowledge, it seems > that the canonical upstream RC snap patches can't be applied to a tree > using either git or old-fashioned patch. No, you're not imagining it, it's definitely happening. What is going on is that I generate patches without the "--binary" flag, which means that git skips the binary diffs entirely. So the diff just contains Binary files a/Documentation/media/media_api_files/typical_media_device.pdf and b/Documentation/media/media_api_files/typical_media_device.pdf differ Then, when you do "git apply", "git apply" will see that, and try to use the index lines to regenerate the thing, which obviously only works in a repository that already _has_ those objects. This is actually not new. I've skipped binary files for the last ten years or so in the diffs, because the diffs are completely illegible, and nobody has ever cared - and non-git users haven't been able to use them anyway. Obviously, part of it is too that we simply don't have very many binary files, so it almost never ends up being a problem. The documentation changes made them happen now. But quite frankly, I see the tar-balls and diffs as a way to have non-git people have a minimally working system, and their *only* point is for people who don't have git. And since plain "patch" cannot handle git binary diffs anyway, there was never any valid reason to include the binary diffs in the diff. Btw, this is why the diffs don't have renames either. The diffs would often be much smaller, and certainly much more legible, if I used the "-M" or "-C" flags, but since the primary reason for the tarballs and diffs existing is for non-git users, and traditional "patch" doesn't understand rename diffs, I don't do it. (Yes, modern GNU patch has actually grown support for rename diffs, although last I looked it gets it wrong for some of the more complex cases - notably cross renames). Summary: - if you have git, you shouldn't use the tar-balls and patches - if you don't have git, binary patches and renames wouldn't work for you anyway, so generating them is pointless and would potentially keep you from getting a working tree. I could easily add "--binary" to my script, because I _think_ traditional "patch" will just ignore it as noise, but I'd honestly rather discourage people from downloading full tar-balls in the first place. Hmm? Linus