lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyKRRDaohVPDSXZ5BRCHqAXAJv16EHS=aCj4B09VYrr6A@mail.gmail.com>
Date:	Wed, 24 Jul 2013 10:24:39 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	"gregkh@...uxfoundation.org >> Kroah-Hartman, Greg" 
	<gregkh@...uxfoundation.org>, Shuah Khan <shuah.kh@...sung.com>,
	Shuah Khan <shuahkhan@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [ 000/103] 3.10.3-stable review

On Wed, Jul 24, 2013 at 10:16 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> I don't know why "git apply" doesn't do it by default. Why would you
> want to apply a patch without having git track new files?

There's a few reasons for the behavior:

 - it turns out that for most simple patches, you don't want to add
them to the index, and you want to stage them separately. Doing a "git
apply", you'd normally expect the end result to not be staged, so that
it shows up in "git diff", and then you can do your normal "git add"
or "git commit -a" or whatever. Yes, this means that you need to know
about new files, but the expected use is *not* to apply a patch
blindly and then not even care about the index.

 - "git apply" is actually also designed to be a *replacement* for
"patch". In particular, you can use it outside a git repository,
exactly like you'd use the standard "patch" program. Except unlike the
standard "patch" program, "git apply" doesn't accept fuzz by default
(which to me is a huge deal - I hate how "patch" tries to apply stuff
that clearly isn't valid any more) and also knows about things like
file modes and renames etc.

That second part is something not enough people use, and when I make
patches and tar-balls I still generate the old-style non-rename
patches etc for that reason. But basically the command is designed to
also be used in non-git environments, so the "standard usage" is very
much not the "involve git details" behavior.

Most "true git" workflows end up using "git am" (or, better yet, "git
pull" etc) to apply patches, which obviously not only does the --index
thing, but also applies the changelog etc.

            Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ