Re: [PATCH v10] tilegx network driver: initial support
From: Chris Metcalf <hidden>
Date: 2012-06-07 20:47:29
Also in:
lkml
On 6/7/2012 4:44 PM, Chris Metcalf wrote:
On 6/7/2012 4:39 PM, David Miller wrote:quoted
From: Chris Metcalf <redacted> Date: Fri, 6 Apr 2012 16:42:03 -0400quoted
Date: Fri, 6 Apr 2012 16:42:03 -0400You did not commit this file on April 6th. Please don't use the date emitted by the GIT tools, just let the email use the natural correct date which is the one at the time you send the email out. Otherwise your patch gets misordered as automated tools like patchwork think this file should go all the way at the back of the patch queue because of it's old date relative to other pending patches.Yes, when I use "git rebase" to merge changes into the earlier patch, this is the behavior I see. I don't know if there's some way to tell git to take the date on the later change instead when I "squash" them. Or if, perhaps, there is some other workflow I should be using. It does seem like the git history should reflect the latest time. The issue of the date on the email is separate. I tend to use "git format-patch" to start with, munge up the headers to jam in some "In-Reply-To" and "References" lines, manually update the "Date:", then feed it to "sendmail -t". Perhaps there's a different workflow I should be using there, too. (I tried deleting the "Date", but the one time I tried that I ended up with some surprisingly bogus date in the email that hit LKML, so I've been avoiding that approach.) I'll resend the patch without a Date: line and see how it ends up this time.
Well, I see where the sendmail "Date:" weirdness was coming from; for some reason "git format-patch" was emitting a first line like this: "From 4d76049b3a48f1b32aed1eeb17b4d3a2cb1b1ff6 Mon Sep 17 00:00:00 2001", and sendmail was helpfully pulling the "Date:" line from there. Deleting that line as well does the right thing, as I see from the third version of this patch on LKML. Why git is doing this is a good question. Sorry for the spam, but hopefully that will avoid the issue in the future. -- Chris Metcalf, Tilera Corp. http://www.tilera.com