Re: [PATCH v3 00/13] ci: include a Visual Studio build & test in our Azure Pipeline

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Sun, 6 Oct 2019, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > Range-diff vs v2:
> >
> >   1:  4d0b38125a =  1:  4d0b38125a push: do not pretend to return `int` from `die_push_simple()`
> >   2:  8800320590 <  -:  ---------- msvc: avoid using minus operator on unsigned types
> >   -:  ---------- >  2:  7fe2a85506 msvc: avoid using minus operator on unsigned types
> >   3:  8512a3e96d =  3:  e632a4eef4 winansi: use FLEX_ARRAY to avoid compiler warning
>
> This is less useful than it could be.
>
> With a larger creation-factor (and we can afford using a larger one,
> simply because the user of GGG _knows_ that the two series being
> compared are closely related), what is output is entirely readable
> (attached at the end).

I just implemented this here:
https://github.com/gitgitgadget/gitgitgadget/pull/128 (it still needs to
be reviewed and merged before it takes effect).

> Oh, while I am suggesting possible improvements on GGG, can we
> please tweak the sender date like git-send-email does so that two
> messages in the same series do not share the same timestamp?  When
> multi-patch series are displayed in MUA or public-inbox News feed
> out of order, it almost always is from GGG that gave the same
> timestamp to adjacent messages in a series, and it prevents me from
> applying them in one go (or saving in one action to a mbox).
>
> What send-email does is, at the beginning for N patch series, to
> take the current wallclock time and subtract N seconds from it, and
> then give that timestamp to the first message it sends out, and
> after that, it increments the timestamp by 1 seconds.
>
> Note that there is no need for any "sleep"---the timestamps are
> given by explicitly generating the "Date: " header.  The last time
> we looked into this issue, I think the code was trying to do almost
> the right thing but it was giving a malformatted timezone and forcing
> the sending MTA to override it with the wallclock time or something.

You mentioned this before, and I implemented it. But GMail ignores the
`Date:` header sent by GitGitGadget, and I don't know why. See e.g.
https://public-inbox.org/git/4d0b38125a13d85963be5e524becf48271893e2b.1570201763.git.gitgitgadget@gmail.com/raw

	[...]
	Date:   Fri, 04 Oct 2019 08:09:25 -0700 (PDT)
	[...]
	X-Google-Original-Date: Fri, 04 Oct 2019 15:09:10 GMT
	[...]

I am fairly certain that the latter is the actual `Date:` line sent to
GMail, and GMail just decides that it will not respect it.

Once https://github.com/gitgitgadget/gitgitgadget/pull/125 makes it into
GitGitGadget (adding the `/preview` command that allows to send patch
series to the PR owner as a test), it should be easier to start
investigating further.

Unless anybody here knows why GMail rejects the header. Maybe it is the
`GMT`?

Ciao,
Dscho