On Thu, May 4, 2017 at 3:24 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <ava...@gmail.com> 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.
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.
