linux-kernel - Re: [PATCH 06/18] x86 vDSO: arch/x86/vdso/vdso32

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.0.9999.0711261745160.5869@woody.linux-foundation.org>
Date:	Mon, 26 Nov 2007 17:53:46 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Roland McGrath <roland@...hat.com>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/18] x86 vDSO: arch/x86/vdso/vdso32

On Tue, 20 Nov 2007, Roland McGrath wrote:
>
> > git format-patch -p
> > 
> > does the trick at least here :)
> 
> Ok, I can use that in future.  I hope it still means that in the eventual
> merged state, GIT will be aware of all the renames.

Git doesn't care. You can do renames by hand, or with "git mv", you can do 
them as a delete/create pair, you can use "git-apply" with a rename patch, 
and you can do them by re-typing in all of the file contents from scratch.

Regardless of how the rename is done, git will represent the data the 
exact same way: the state of the tree before and after. 

The rename-patches are a lot denser and a lot more readable for humans (ie 
you can actually see what *happens*, unlike a traditional stupid unified 
diff), and I was hoping that eventually somebody in the GNU patch 
community would see how wonderful the extended patch information is, but 
when I tried to write a patch to "patch" to do it, I almost dug out my 
eyes with spoons from looking at the source code, so I haven't actually 
helped it happen.

So you can ask for patches in traditional format (*most* git command lines 
will default to that anyway, and only give a copy-patch with -C or -M on 
the command line), or people could realize that "git-apply" actually works 
even on non-git source code, and just stop using that abomination that is 
"patch" with all of it's totally wrong and unsafe defaults (*).

But whatever works. I'm currently skipping the patches since they didn't 
seem like 2.6.24 fodder anyway.

			Linus

(*) Let me count the ways: applying patches partially when it fails 
half-way through a series. Defaulting to totally randomly guessing the 
path-name skip depth when not explicitly given a -pX option. Defaulting to 
"--fuzz=2" which is almost guaranteed to apply a patch even when it makes 
no sense what-so-ever. Yes, git-apply has stricter rules, but they are 
stricter for damn good reasons. For people who want the insane unsafe GNU 
patch defaults, they just have to specifically ask for unsafe modes..
-
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/