linux-kernel - Re: [GIT]: Networking

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: <alpine.LFD.2.00.0901052029220.3057@localhost.localdomain>
Date:	Mon, 5 Jan 2009 20:37:58 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
cc:	akpm@...ux-foundation.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT]: Networking

On Mon, 5 Jan 2009, David Miller wrote:
> 
> As an aside, is there a way to make git-am and other stuff using the
> git patch applying engine to take patches liberally like 'patch'
> would?

Well, "git apply" takes flags like "-C1" to accept fuzzy patches, and 
--whitespace=fix etc to apply them despite whitespace differences etc. 

And at least more modern versions of "git am" should take them and pass 
them on. Although I'd generally not encourage that much. Partly because I 
hate how often it has screwed up over the years thanks to GNU patch 
accepting any random crud.

So out of that, if I personally have a patch that only applies with fuzz 
and I know I still want to apply it, I just go and manually edit away the 
parts that no longer match in the patch itself (and fix up the line 
counts etc). But that's obviously me, and I'm very comfy editing patches 
directly.

But another quite useful approach is to just try to apply the patch to the 
version that it was done against - preferably in a separate branch - and 
then just merging the end result. 

> The default is extremely strict, which makes me check things out by
> hand.  That's good, but as I add the change by hand after verifying
> it's sanity I often make mistakes that result in things like the above
> missed delete, so if I could ask git to be non-strict it would help me
> out a lot.

Yeah, I know, "git am" really is very strict, and sometimes annoyingly so. 
But it _can_ be overridden. And if the other end uses git to generate the 
patch, you can also do a three-way apply, which really tends to work. But 
that requires that the patch have the SHA1 ID's of the original blobs (and 
that you have those blobs - ie that the patch was really generated against 
something you already had)

			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/