On Mon, Jul 16, 2018 at 02:54:38PM +0100, Ramsay Jones wrote: > On 16/07/18 14:00, Derrick Stolee via GitGitGadget wrote: > > There are many places in Git that use a commit walk to determine > > reachability between commits and/or refs. A lot of this logic is > > duplicated. > [snip] ... > > This is not your problem, but I find these GitGitGadget > submissions somewhat annoying. This series has been spewed > all over my in-box in, what I assume, is commit date order. > > So, patches #4,5 dated 19/06, then #1,2,3 dated 25/06, > then #15 dated 28/06, then #6,7 dated 12/07, then #8-16 > dated 13/07, then 00/16 dated today. > > No I don't use a threaded display (I hate it), be even with > that turned on, the patches still appear in the above order > under the cover letter (but at least all together). Yeah, they're out of order in mutt's threaded display. And the back-dating means there's a much higher chance of them getting blocked as spam (e.g., some of the dates are from weeks ago). git-send-email uses the current time minus an offset, and then monotonically increases for each patch: $time = time - scalar $#files; ... my $date = format_2822_time($time++); which seems to work pretty well in practice. It does mean the original dates are lost. The committer date is not interesting at all (there will be a new committer via "git am" anyway). The original author date is potentially of interest, but could be included as an in-body header. AFAIK send-email doesn't have such an option, though, and people are fine with date-of-sending becoming the new author date. +cc Johannes as the GitGitGadget author -Peff
