Konstantin Ryabitsev <[email protected]> wrote: > I'm just worried that if we overuse the alternates, then we may find ourselves > in a situation where when we repack the "every blob" shared repository, we'll > end up with a pack that isn't really optimized to be used by any of the > member repos. So, in a situation where a clone is performed, git-upload-pack > will have to spend a lot of cycles navigating through the monstrous parent > pack just to build and re-compress the small subset of objects it needs to > send. > > Git has ways of dealing with this by allowing to set things like pack islands, > but it's finicky and requires that each child repo is defined as refs in the > parent repo. We deal with this in grokmirror, but it's messy and requires > properly tracking child repo additions/removals/etc.
At least for personal use, I've been meaning to look into automatically managing islands. > I think it may be one of those cases where wasting disk space on duplicate > objects is worth the CPU cycle savings. Agreed for serving public inboxes. > On Mon, Apr 26, 2021 at 06:47:17PM +0000, Eric Wong wrote: > > The aforementioned maxuid prevents stuff that's too old from > > being seen. Otherwise, there's always "public-inbox-learn rm". > > How would it handle the situation where we import a new list into lore with a > 10-year-long archive of messages? maxuid is either per-inbox or per-extindex. If the search is going off of inboxes via --only, then it would not see the new inbox at all. If it's on an extindex like "all", then yes, the newly-imported historical messages would show up. So using "rt:" (Received time) is helpful in the [extindex "all"] case Also, the approxidate parsing is done every time with "lei up", so you can have a rolling window with "rt:last.week.." as a search parameter. -- unsubscribe: one-click, see List-Unsubscribe header archive: https://public-inbox.org/meta/
