On 2020-10-15 at 19:05:32, Jeff King wrote: > On Thu, Oct 15, 2020 at 11:35:28AM -0700, Junio C Hamano wrote: > > > For this particular case, what we need is a functioning > > patch tracker *and* people who pay attention to patches in the "came > > very close to conclusion but no final patch in the tree" state. We > > need people who can volunteer their eyeballs and attention to nudge, > > prod and help patches to perfection, and that won't be me. > > Usually I'd expect this to be the responsibility of the patch submitter > to make sure their stuff gets merged (and if not, to figure out why). Normally I try to keep up with what's cooking emails, but I remember the original bug report came in on a day when I had some other event and I probably got distracted with whatever else I was doing later and forgot about keeping up with the patch. It would be very convenient if we did have a functioning patch tracker which could be looked up by user, because then it'd be easier to monitor one's own series. > Personally I make a branch for almost every patch/series I submit, no > matter how trivial[1]. And then part of my daily ritual is seeing which > ones have been merged, and dropping them. You can use git-cherry for > that, though it's not 100% perfect (sometimes patches are munged as they > are applied). I use a combination of that and aggressively rebasing > patches forward (and eventually they rebase down into nothing when > they've been fully merged). I'm really terrible at deleting data, so I have (exactly) 256 branches in my local repository. Some of them are merged, and some are not. This would be a viable approach if I were better about deleting old series (and completing and sending in the prototypes I've built), or if I sent in series that were smaller so rebasing them were not so big of a time commitment. -- brian m. carlson (he/him or they/them) Houston, Texas, US
Attachment:
signature.asc
Description: PGP signature
