mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Roland McGrath <roland@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 06/18] x86 vDSO: arch/x86/vdso/vdso32
Date: Mon, 26 Nov 2007 17:53:46 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.0.9999.0711261745160.5869@woody.linux-foundation.org> (raw)
In-Reply-To: <20071120232715.0803426F8BE@magilla.localdomain>



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..

  parent reply	other threads:[~2007-11-27  1:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-19 21:59 [PATCH 00/18] x86 vDSO revamp Roland McGrath
2007-11-19 22:01 ` [PATCH 01/18] x86 vDSO: generate vdso-syms.lds Roland McGrath
2007-11-19 22:02 ` [PATCH 02/18] x86 vDSO: use vdso-syms.lds Roland McGrath
2007-11-19 22:02 ` [PATCH 03/18] x86 vDSO: remove vdso-syms.o Roland McGrath
2007-11-19 22:03 ` [PATCH 04/18] x86 vDSO: new layout Roland McGrath
2007-11-19 22:03 ` [PATCH 05/18] x86 vDSO: harmonize asm-offsets Roland McGrath
2007-11-19 22:04 ` [PATCH 06/18] x86 vDSO: arch/x86/vdso/vdso32 Roland McGrath
2007-11-20 13:05   ` Thomas Gleixner
2007-11-20 20:57     ` Roland McGrath
2007-11-20 23:07       ` Thomas Gleixner
2007-11-20 23:27         ` Roland McGrath
2007-11-20 23:50           ` Thomas Gleixner
2007-11-27  1:53           ` Linus Torvalds [this message]
2007-11-27  2:01             ` Roland McGrath
2007-11-19 22:05 ` [PATCH 07/18] x86 vDSO: vdso32 build Roland McGrath
2007-11-21  6:02   ` Sam Ravnborg
2007-11-21  7:10     ` Roland McGrath
2007-11-21  7:32       ` Sam Ravnborg
2007-11-21  7:55         ` Roland McGrath
2007-11-19 22:05 ` [PATCH 08/18] x86 vDSO: i386 vdso32 Roland McGrath
2007-11-19 22:05 ` [PATCH 09/18] x86 vDSO: absolute relocs Roland McGrath
2007-11-19 22:05 ` [PATCH 10/18] x86 vDSO: i386 vdso32 install Roland McGrath
2007-11-19 22:06 ` [PATCH 11/18] x86 vDSO: vdso32 setup Roland McGrath
2007-11-19 22:06 ` [PATCH 12/18] x86 vDSO: ia32_sysenter_target Roland McGrath
2007-11-19 22:06 ` [PATCH 13/18] x86 vDSO: ia32 sysenter_return Roland McGrath
2007-11-21  0:05   ` Zachary Amsden
2007-11-21  0:34     ` Roland McGrath
2007-11-19 22:06 ` [PATCH 14/18] x86 vDSO: ia32 vdso32-syscall build Roland McGrath
2007-11-19 22:06 ` [PATCH 15/18] x86 vDSO: consolidate vdso32 Roland McGrath
2007-11-21  0:13   ` Zachary Amsden
2007-11-21  0:13     ` Ingo Molnar
2007-11-21  0:15     ` Andi Kleen
2007-11-21  0:32     ` Roland McGrath
2007-11-19 22:06 ` [PATCH 16/18] x86 vDSO: ia32 vsyscall removal Roland McGrath
2007-11-19 22:07 ` [PATCH 17/18] x86 vDSO: reorder vdso32 code Roland McGrath
2007-11-19 22:07 ` [PATCH 18/18] x86 vDSO: makefile cleanup Roland McGrath

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=alpine.LFD.0.9999.0711261745160.5869@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=roland@redhat.com \
    --cc=tglx@linutronix.de \
    /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

all inboxes | Powered by JetHome®