Re: [PATCH] fast-import: fix over-allocation of marks storage

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 16, 2020, 03:18 UTC
Message-ID: <20201016031834.GE490427@camp.crustytoothpaste.net>
In-Reply-To: <20201015190532.GB1108210@coredump.intra.peff.net>

On 2020-10-15 at 19:05:32, Jeff King wrote:

Show 10 quoted lines

> 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.

Show 7 quoted lines

> 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