Re: [PATCH v2 0/9] Teach 'run' perf script to read config files

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 27, 2017, 00:04 UTC
Message-ID: <xmqq4lrp9fct.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAFY1edZ6FX6s+H_XWa-=nKqr4NA9BNVxR6fcOo+5gn-Z1XKdUg@mail.gmail.com>

Roberto Tyley <roberto.tyley@gmail.com> writes:

Show 11 quoted lines

> I had a quick look at git-send-email.perl, I see the trick is the `time++` one
> introduced with https://github.com/git/git/commit/a5370b16 - seems reasonable!
>
> SubmitGit makes all emails in-reply-to the initial email, which I
> think is correct behaviour,
> but I can see that offsetting the times would probably give a more
> reliable sorting in
> a newsreader. ...
> ...so the only way SubmitGit can offset the times is to literally
> delay the sending of the emails,
> which is a bit unfortunate for patchbombs more than a few dozen commits long!

As this matters mostly for a series that is longer than several patches, it indeed is unfortunate. If SubmitGit needs to send and sleep for a dozen messages, does it mean the end user has to wait 12 (or is it 11? ;-)) seconds? If the human is the only thing that needs waiting, it may be OK (after all, it all happens in the web browser and the human can switch to other tasks after clicking "submit"), but that may not be acceptable if this artificial delay can cause a timeout in a moving part among many.

Thanks for looking into this.