linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jarod Wilson <jarod@redhat.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <greg@kroah.com>
Subject: Re: Linux-4.X-rcY patches can't be applied with git?
Date: Mon, 24 Oct 2016 12:24:31 -0700	[thread overview]
Message-ID: <CA+55aFy-HHBWTRQdSGReJXhm+HgcJshN4=-Nqq-W2ookfQ5D2g@mail.gmail.com> (raw)
In-Reply-To: <20161024182503.GH42084@redhat.com>

On Mon, Oct 24, 2016 at 11:25 AM, Jarod Wilson <jarod@redhat.com> 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

  reply	other threads:[~2016-10-24 19:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 18:25 Linux-4.X-rcY patches can't be applied with git? Jarod Wilson
2016-10-24 19:24 ` Linus Torvalds [this message]
2016-10-24 21:02   ` Josh Boyer
2016-10-24 21:10     ` Linus Torvalds
2016-10-24 21:27       ` Jarod Wilson
2016-10-24 21:45         ` Linus Torvalds
2016-10-24 23:18           ` Jarod Wilson
2016-10-25  0:06             ` Linus Torvalds
2016-10-25  2:49               ` Jarod Wilson
2016-10-25 11:36                 ` Josh Boyer
2016-10-29 21:08               ` Linus Torvalds
2016-10-31 13:15                 ` Laura Abbott
2016-10-31 14:55                 ` Jarod Wilson
2016-11-08 20:43               ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+55aFy-HHBWTRQdSGReJXhm+HgcJshN4=-Nqq-W2ookfQ5D2g@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=jarod@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).