Re: Gmail munges dates?

[Jeff King <peff@peff.net>]

On Thu, Dec 12, 2019 at 05:57:53PM -0800, Denton Liu wrote:

> It seems like Gmail is munging the dates on patches sent. Before today,
> I've been sending patches out with mutt but I decided to switch to
> git-send-email today since I was forwarding a patch that wasn't mine and
> I wanted to preserve the date as part of the authorship information.
> 
> Unfortunately, it seems like mutt wasn't the culprit, it was Gmail
> that's been munging the dates. For example, in this patch[1], the date
> shows as
> 
> 	Date: Thu, 12 Dec 2019 16:44:50 -0800
> 
> even though locally, the output of the format-patch shows as
> 
> 	Date: Mon, 9 Dec 2019 19:25:34 +0100

Both mutt and git-send-email will munge the headers. And they really
need to, since sending a message whose Date header is several days old
(or much more, in some cases) is likely to trigger spam filters.

> So two questions related to this:
> 
> 1. Is this something that we care about or is it okay to have fudged
> dates? (I know all of my patches in each patchset only differ by a few
> seconds and it seems like no one has noticed or cared so far)

It's OK to have fudged dates. In fact, I think you could make an
argument that it's preferable for our development flow. It treats the
patch hitting the list as the moment of authorship. When reading "git
log" later, that would put its author date near its peers. Of course in
a non-linear history you probably care more about "when did this hit
master", but the author timestamps are a rough approximation for "era".
And of course the committer information could tell you more there, but
we don't tend to show it by default.

So I think there are philosophical arguments to be made, but for
practical purposes, I think everybody is reasonably happy with the
current mechanisms.

There are cases when you might want to preserve old date information
(say, re-sending a patch that was several years old). Usually in that
case I'd leave the author date as current but make a note about the
patch's history if it's relevant.


> 2. Do we want to introduce a --in-body-date option or something to
> format-patch which would include an in-body Date:, similar to the
> in-body From:? (Also, while we're at it, maybe we could include an
> --in-body-from to force that to happen since that's been a feature that
> was requested in the past[2])

I doubt I'd use it myself, but I wouldn't be opposed to an in-body-date
option. You'd perhaps want to define some heuristics to avoid
uninteresting noise. If your patch is from 10 minutes ago, and you are
just now sending it in, adding the extra date header is mostly just
clutter. So perhaps you'd want it to kick in when the date is more than
N time units or something.

-Peff