From: Jarod Wilson <jarod@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Josh Boyer <jwboyer@fedoraproject.org>,
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 22:49:59 -0400 [thread overview]
Message-ID: <20161025024959.GL42084@redhat.com> (raw)
In-Reply-To: <CA+55aFwt3yoDkSY2TBo5uCYa2B_BhWXGVVBEN=9G-6WWXB__1w@mail.gmail.com>
On Mon, Oct 24, 2016 at 05:06:42PM -0700, Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 4:18 PM, Jarod Wilson <jarod@redhat.com> wrote:
> >
> > But in that case, what if your patch generation script used a filter to
> > exclude those binary files? No harm to that target audience, and it would
> > actually make them behave better for distro builds. Though that might be
> > counter to the goal of making them disappear entirely. :)
>
> Heh, I'd rather people get the warning that "oops, something is
> incomplete". They can still work with the end result, but at least
> they got some indication that hey, that patch didn't work wonderfully
> well...
>
> To be honest, I really would like to not do the tar-balls and patches at all.
>
> But maybe rather than saying "it's only for legacy 'patch' users", I
> could just say that it's getting phased out, and say "you have to use
> 'git apply' to apply them".
>
> Then I could just enable "--binary" and "-M", and see what happens.
I like this idea!
> I suspect that these days, git is so ubiquitous that it's ok.
>
> And then in a few years, maybe I can just stop doing patches entirely,
> having proved the point that everybody already has git ;)
Honestly, the only people that don't have access to git to pull down
kernel sources? People who haven't yet got a kernel up and running, who
will probably get there via a distro kernel. ;)
Side note in favor of tarballs: I know Fedora likes upstream to have
tarballs, with checksums provided, so that packages can be verified to
contain a legitimate upstream source tarball, rather than a random tarball
created by the packager that could have some extraneous bits (possibly
malicious) added to them. One can certainly examine and validate a
generated tarball too, but it's a fair bit more work than just "does the
checksum match?" and not as easily automated.
--
Jarod Wilson
jarod@redhat.com
next prev parent reply other threads:[~2016-10-25 2:50 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
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 [this message]
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=20161025024959.GL42084@redhat.com \
--to=jarod@redhat.com \
--cc=greg@kroah.com \
--cc=jwboyer@fedoraproject.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.