Ævar Arnfjörð Bjarmason [off-list ref] writes:
It makes sense to have a configurable delay for git-send-email
unrelated to this option, I'd use a facility like that.
A lot of mail clients just sort based on date/msgid or whatever not
date/subject, so the rapid-fire output of send-email often arrives out
of order because it's all sent at the same second. I'd use some option
where I could send a series as "all" and have it sleep(N) in between
sending mails.
Hmph. When sending many messages, send-email first grabs the
current time, counts backwards N seconds for N message series,
and uses that timestamp that is N seconds in the past for the first
message, incrementing the timestamp by 1 second per each subsequent
ones.
I found that this trick is sufficient to cause receiving MUAs sort
messages based on date, as the Date: field will have the timestamps
that increases by 1 second in between messages in a batch.
There might be MUAs that do not use the value of the Date: field
when told to sort by date (perhaps they use the timestamp of the
message file they received at the final hop to them?), but it is
hopeless to help such MUAs unless the mail path guarantees the order
at the originator, which is not how "store and forward" e-mails
work.
So...
For the list, in plain text:
IIUC, they use the date received to sort. I think this might stem from
a historical cruft: emails sometimes took non-trivial amounts of time
to transit, back in the old days. MUAs (especially web-based ones)
probably did not want to violate user expectation by placing a new
email under several already-read emails. I would argue that this was
reasonable behavior. Further, since email is near-instantaneous today,
it really makes no difference which way the MUA sorts. Except for git
send-email.
It might be acceptable to put in a "practical hack" to help out MUAs
in the context of "near instant forwarding". I would argue against it
on grounds of it being an ugly hack, for very little benefit. The
patch that began this thread is also ugly, but has the important
consequence of enabling some people to use git send-email at all.
p.s- We should probably allow emails from mobile devices on the list.
It usually contains a HTML subpart.
On Thu, May 4, 2017 at 3:24 AM, Junio C Hamano [off-list ref] wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
It makes sense to have a configurable delay for git-send-email
unrelated to this option, I'd use a facility like that.
A lot of mail clients just sort based on date/msgid or whatever not
date/subject, so the rapid-fire output of send-email often arrives out
of order because it's all sent at the same second. I'd use some option
where I could send a series as "all" and have it sleep(N) in between
sending mails.
Hmph. When sending many messages, send-email first grabs the
current time, counts backwards N seconds for N message series,
and uses that timestamp that is N seconds in the past for the first
message, incrementing the timestamp by 1 second per each subsequent
ones.
I found that this trick is sufficient to cause receiving MUAs sort
messages based on date, as the Date: field will have the timestamps
that increases by 1 second in between messages in a batch.
There might be MUAs that do not use the value of the Date: field
when told to sort by date (perhaps they use the timestamp of the
message file they received at the final hop to them?), but it is
hopeless to help such MUAs unless the mail path guarantees the order
at the originator, which is not how "store and forward" e-mails
work.
As Ramkumar points out many MUAs don't sort by Date because of mail
delays / inaccurate sender clocks. Fun fact: You happen to work for a
company making one such MUA :)
E.g. just to name one example in my GMail view (it's full of this sort
of thing) Stefan Beller's recent cache.h series starts in the order
01/03/02 (and continues out of order).
The Date headers on the messages themselves are incremented by 1
second as you note, but on those first 3x the Recieved chain ends in
this for all 3:
Received: by 10.28.48.210 with SMTP id w201csp570755wmw;
Tue, 2 May 2017 15:24:50 -0700 (PDT)
I.e. all Received on the same second, showing that the Date header is
ignored by GMail, just from observing it GMail's sort function seems
to be (pseudocode):
a['Received'] <=> b['Reiceved'] || a['GMailInternalID'] <=>
b['GMailInternalID']
Not:
a['Received'] <=> b['Reiceved'] || a['MessageID'] <=>
b['MessageID'] || a['GMailInternalID'] <=> b['GMailInternalID']
Or:
a['Received'] <=> b['Reiceved'] || a['Subject'] <=> b['Subject']
|| a['MessageID'] <=> b['MessageID'] || a['GMailInternalID'] <=>
b['GMailInternalID']
Or:
a['Received'] <=> b['Reiceved'] || a['Date'] <=> b['Date'] ....
Anyway, you get the idea, but all of these would cause it to show
git-send-email list traffic in order, since while the Received field
is the same both Date & MessageID is different & sortable (actually
not quite, but that's another matter).
When I send my own patches with git-send-email I tend to sit there
hitting "y" in succession instead of doing "a" because I like being
able to browse my patches in order, which I guess tells you something
about my tolerance for tedium before submitting a patch to sleep().
If you look at GMail's web view you can effectively also see how close
someone is to Google's servers by how out of order their patches are,
e.g. your patches, Stefan's etc. & other Google employees working in
SV are pretty much entirely shuffled, whereas Michael Haggerty's are
pretty much in order because his mailpath involves a transatlantic &
trans-US-costal route before being delivered.