git send-email sets date

git send-email sets date

[Michal Suchánek]

Hello,

git send-email sets the message date to author date.

This is wrong because the message will most likely not get delivered
when the author date differs from current time. It might give slightly
better results with commit date instead of author date but can't is
just skip that header and leave it to the mailer?

It does not even seem to have an option to suppress adding the date
header.

Thanks

Michal

Re: git send-email sets date

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Fri, Jan 26, 2018 at 06:32:30PM +0100, Michal Suchánek wrote:
> git send-email sets the message date to author date.
> 
> This is wrong because the message will most likely not get delivered
> when the author date differs from current time. It might give slightly
> better results with commit date instead of author date but can't is
> just skip that header and leave it to the mailer?
> 
> It does not even seem to have an option to suppress adding the date
> header.

I'm pretty sure it's intended to work this way.

Without the Date header, we have no way of providing the author date
when sending a patch.  git am will read this date and use it as the
author date when applying patches, so if it's omitted, the author date
will be wrong.

If you want to send patches with a different date, you can always insert
the patch inline in your mailer using the scissors notation, which will
allow your mailer to insert its own date while keeping the patch date
separate.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]

RE: git send-email sets date

[Philip Oakley]

Behalf Of brian m. carlson
> On Fri, Jan 26, 2018 at 06:32:30PM +0100, Michal Suchánek wrote:
> > git send-email sets the message date to author date.
> >
> > This is wrong because the message will most likely not get delivered
> > when the author date differs from current time. It might give slightly
> > better results with commit date instead of author date but can't is
> > just skip that header and leave it to the mailer?
> >
> > It does not even seem to have an option to suppress adding the date
> > header.
> 
> I'm pretty sure it's intended to work this way.
> 
> Without the Date header, we have no way of providing the author date
> when sending a patch.  git am will read this date and use it as the
> author date when applying patches, so if it's omitted, the author date
> will be wrong.
> 
> If you want to send patches with a different date, you can always insert
> the patch inline in your mailer using the scissors notation, which will
> allow your mailer to insert its own date while keeping the patch date
> separate.
> --

Michal, you may want to hack up an option that can automatically create 
that format if it is of use. I sometimes find the sort order an issue in 
some of my mail clients.
--
Philip

Re: git send-email sets date

[Theodore Ts'o]

On Sun, Jan 28, 2018 at 03:56:57PM -0000, Philip Oakley wrote:
> Michal, you may want to hack up an option that can automatically create 
> that format if it is of use. I sometimes find the sort order an issue in 
> some of my mail clients.

If there is a From: header in the beginning of the mail body, it is
used as the Author instead of the From: header in the mail header.  It
would make sense if there is a Date: header in the beginning of the
mail body, it should be used instead of Date: field in the mail header.

The problem is that if existing git clients don't support this, it
wouldn't be safe to start emmiting patches with that format for at
least a year or two until the prerequisite version of git gets wide
adoption.  Alternatively, there could be a git option which causes
something like X-Git-Author-Date: to be set in the mail header.

	       			  	   	- Ted

Re: git send-email sets date

[Junio C Hamano]

Theodore Ts'o <tytso@mit.edu> writes:

> If there is a From: header in the beginning of the mail body, it is
> used as the Author instead of the From: header in the mail header.  It
> would make sense if there is a Date: header in the beginning of the
> mail body, it should be used instead of Date: field in the mail header.

Just like From:, Date: and Subject: are in-body headers that are
accepted by deployed versions of "git am" (actually, "mailinfo").

Re: git send-email sets date

[Ævar Arnfjörð Bjarmason]

On Fri, Jan 26, 2018 at 6:32 PM, Michal Suchánek <msuchanek@suse.de> wrote:
> This is wrong because the message will most likely not get delivered
> when the author date differs from current time.

Others have covered other bases here, but I just wanted to ask about
this. Are there really mail setups that refuse to deliver or accept
messages whose Date headers don't match what the expect? I would think
that such issues wouldn't be present in the wild since SMTP daemons
need to deal with messages that are e.g. held locally somewhere, or
the only make it to your server days afterwards due to your own
downtime + client retries.

Now if by "not get delivered" you mean they'll show up on the Nth page
of your mailer because it sorts by the Date header, sure. That's a
problem and quite common, tricky to solve due to the issues others
have noted though.

Re: git send-email sets date

[Eric Wong]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On Fri, Jan 26, 2018 at 6:32 PM, Michal Suchánek <msuchanek@suse.de> wrote:
> > This is wrong because the message will most likely not get delivered
> > when the author date differs from current time.

Even by a few seconds?  I guess it depends on how many patches
you're sending at once.  It uses number of patches to set Date:
header:

	$time = time - scalar $#files;
	(and does $time++ for each patch)

> Others have covered other bases here, but I just wanted to ask about
> this. Are there really mail setups that refuse to deliver or accept
> messages whose Date headers don't match what the expect? I would think
> that such issues wouldn't be present in the wild since SMTP daemons
> need to deal with messages that are e.g. held locally somewhere, or
> the only make it to your server days afterwards due to your own
> downtime + client retries.

Having a Date that's far off is one of many indicators used to
determine spam.  SpamAssassin has a rules and scores which do
this, but it looks like the smallest one is for 3 and 6 hours
in the past (DATE_IN_PAST_03_06) so one would need 10800 patches
to trigger it (!?)

I definitely had problems back in the day with author date
being used as the Date: header, see:

	commit 1d6a003a42b3c23ad7883b0bbe6a034728e51836
	("git-send-email: do not pass custom Date: header")

Re: git send-email sets date

[Junio C Hamano]

Michal Suchánek <msuchanek@suse.de> writes:

> git send-email sets the message date to author date.
>
> This is wrong because the message will most likely not get delivered
> when the author date differs from current time. It might give slightly
> better results with commit date instead of author date but can't is
> just skip that header and leave it to the mailer?
>
> It does not even seem to have an option to suppress adding the date
> header.

I think you are complaining about output from "git format-patch",
and the reason why the date header is recorded in the output is as
others already mentioned in this thread.

The complaint about "delivery" is misplaced because that date is not
used to drive the SMTP conversation in any way.  "git send-email"
does create its own timestamp, but that is based on the current time
and does not have anything to do with the author or committer date
of the original commit the patch message came from.  

I think we confused end-users like you by allowing the command to
drive "git format-patch" from the command line (and worse, somehow
appearing to encourage such use), which probably was a UI mistake.
We should encourage people to run two commands separately instead,
which incidentally will allow the patch messages to be proofread for
the last time before they are sent out, but also reduce this
confusion when users see that these dates from the author timestamp
are not used in the "Date:" header of received e-mails.