Skip to contentSkip to conversation

'git format-patch' on older commits, and mailinglist

DISCUSSION Marius Storm-Olsen 2 participants 2 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

Hi,

Recently, I sent out patches which were fixed up with --amend on older commits. When I sent them out, the patches contained
Date: <more than 2 days old datestamp>
in the headers. Now, sending these mails is fine, and mail clients generally handles it perfectly fine. However, after doing this I got an email from [email protected], basically telling me to not do this, since they get a lot of bounces where the return is marked with

    Diagnostic Code: smtp; 550 (4.5 DATE_IN_PAST_48_96 Date: is 48 to 

96 hours before Received: date)

This is understandable. The question is, do we fix the tools to handle this, so that emails are always generated with now() date, and the commit content contains a tag for the original commit; or do we simply say, always send patches to the mailing list with a current timestamp?

Maybe my workflow is incorrect too. I don't mind pointers on this.

I guess rebasing before generating the patch series would have fixed this, but I really didn't need to. I simply reset HEAD~2, fixed with --amend, then cherry-picked the other on top again; then created the patch series.

Signature · 2 lines
.marius
- simply wondering what others on the git mailinglist do..
#1 lore raw
Quoted 8 lines · Marius Storm-Olsen

Recently, I sent out patches which were fixed up with --amend on older commits. When I sent them out, the patches contained
Date: <more than 2 days old datestamp>
in the headers. Now, sending these mails is fine, and mail clients generally handles it perfectly fine. However, after doing this I got an email from [email protected], basically telling me to not do this, since they get a lot of bounces where the return is marked with

Quoted 7 lines
    Diagnostic Code: smtp; 550 (4.5 DATE_IN_PAST_48_96 Date: is 48 to

96 hours before Received: date)

This is understandable. The question is, do we fix the tools to handle this, so that emails are always generated with now() date, and the commit content contains a tag for the original commit; or do we simply say, always send patches to the mailing list with a current timestamp?

I think the right solution would be for send-email to move Date: to the beginning of the body part, just like it adds an extra From: there when the sender is different from the author, and not lie about the mail transmission date.

Then we won't lose the authorship date information in the resulting commit and will still keep the mailpath happy.