Re: [PATCH 00/16] Consolidate reachability logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Peff,

On Mon, 16 Jul 2018, Jeff King wrote:

> 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

Thanks for dumping even more work on my shoulders.

I wanted to help with that insane process we have here, but in a more
collaborative manner.

This time I fixed it, but please do keep in mind that the decision to use
the email transport for something it *was not designed for* (it was
designed for humans talking to humans) is the culprit here.

Next time, I will ask you to jump in, instead of putting the onus on me.

I mean, seriously, what is this? "You can use *any* mail program to work
with the Git mailing list, *any* mailer. As long as it is mutt. And as
long as you spend hours and hours on tooling that oh BTW nobody else can
use."

Hopefully GitGitGadget will make this situation better. And hopefully not
on the expense of my sanity.

Ciao,
Dscho



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux