Gmail munges dates?

Gmail munges dates?

[Denton Liu]

Hi all,

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

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)

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])

Thanks,

Denton

[1]: https://lore.kernel.org/git/8691ed2b84f7ee6b7c12d04d57a541bf22660333.1576197846.git.liu.denton@gmail.com/
[2]: https://lore.kernel.org/git/20191010225405.GA19475@sigill.intra.peff.net/

Re: Gmail munges dates?

[Jeff King]

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

Re: Gmail munges dates?

[Junio C Hamano]

Denton Liu <liu.denton@gmail.com> writes:

> 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

"git send-email" records the timestamp of sending.  If you really
want to force a specific author date, you could add a in-body Date:
but it is discouraged in mailing-list centric workflow, because it
is more natural for everybody other than the author to consider that
the time the patch hits the list, i.e. the public eyes, is when the
patch was "authored".

Re: Gmail munges dates?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>> 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.

I do not have a fundamental objection to the --in-body-date option,
either, although I do not want to see it used when sending patches
to this list.

As long as it is a command-line per-invocation option, I do not
think you'd need any "uninteresting noise filtering" logic.  A
configuration variable to always do so would cause a huge headache
to keep the behaviour sensible when sending one's own patches,
and would require such filtering, I would think.

Thanks.