[U-Boot] [PATCH/next v3 00/28] tools/Makefile cleanup and win32 tool support

[Mike Frysinger]

On Tuesday 17 March 2009 16:59:39 Peter Tyser wrote:
> On Tue, 2009-03-17 at 13:43 -0400, Mike Frysinger wrote:
> > On Tuesday 17 March 2009 13:21:05 Scott Wood wrote:
> > > On Fri, Mar 13, 2009 at 06:54:24PM -0500, Peter Tyser wrote:
> > > > This patch series attempts to do 2 things:
> > > > 1. Add support for generating win32 versions of the tools in tools/
> > > > 2. Cleanup tools/Makefile somewhat
> > > >
> > > > In the process of #1 I couldn't help but work on #2 a bit:)  Let me
> > > > know if people would prefer the patches split up.
> > >
> > > <peeve type="pet">
> > > It's easier to read patchsets, especially large ones, when each message
> > > is a reply to the original rather than to the preceding patch (which
> > > in many mailers makes the subjects appear shifted one character to the
> > > right compared to the parent post, eventually scrolling off the right
> > > edge of the screen).
> > > </peeve>
> >
> > your mailer does just one char ?  i should switch from kmail to whatever
> > you're using :) ...
> >
> > Peter: if you update to git-1.6.2 (well, maybe what i describe happens in
> > earlier versions, but i know 1.6.2 is good), then you can use
> > --cover-letter to `git format-patch` and `git send-email` will thread
> > things the way Scott describes if you send all the patches together: `git
> > send-email 0*.patch`.
> >
> > the cover letter will be the thread starter and all the patches in the
> > series will refer to that one rather than each N patch referring to N-1
> > in the series.
>
> I see similar default threading styles in both 1.6.0 and 1.6.2.  It
> looks like I was missing git send-email's "--no-chain-reply-to"
> argument.  I added "sendmail.chainreplyto = false" to my .gitconfig
> which also does the trick.
>
> It makes me wonder why --chain-reply-to would ever be the default...

i thought they changed that default in recent versions ... but i'd have to 
agree that the default chained to is stupid

btw, if we cant get the windows stuff completely sorted before the next merge, 
you should be able to get all the build and such cleanups which are not 
directly related merged ... then we can get back to picking over mingw :)
-mike