Hi, On Tue, Sep 3, 2013 at 9:09 PM, Thomas Schwinge <tho...@codesourcery.com> wrote: > Hi! > > On Tue, 03 Sep 2013 12:11:02 +0100, Pedro Alves <pal...@redhat.com> wrote: >> On 09/03/2013 10:38 AM, Thomas Schwinge wrote: >> > [strategy] >> >> I've been thinking about this this morning, after seeing these >> patches. >> >> For new gdbserver ports, this path just seems to swim further away from >> a full sharing approach, by adding lots duplication as first step, [...] > >> So my idea would be, [...] > > Understood, and yes, your argumentation is reasonable. > >> I'd do this [by] >> literally moving gdbserver/gnu-low.c on top of gdb/gnu-nat.c (etc.), and >> use git diff to guide me through, in identifying what would need to >> be restored, and guarded with #if[n]def GDBSERVER. [...] > > Yes, that's a nice technique for displaying and integrating the > differences between the existing Hurd native port's files and the new > gdbserver port's. Yue, does the approach of diffing the files as Pedro > described make sense to you? Please tell if you need help with how to > use Git to do that, etc.
Yeah, I will do that. But in my understand, I will use diff gnu-low.c ../gnu-nat.c and something like this. But I don't know how to use git do this. Like git diff a.c b.c? BTW, I got these patches by git diff <early_commit> > gdb.patch. Then I edit the patch to two file. When I use git format-patch <early_commit> I will get a patche for each commit after the early_commit. What is the better way you generate patches? -- Yue Lu (陆岳)
