From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN:  
X-Spam-Status: No, score=-4.2 required=3.0 tests=ALL_TRUSTED,BAYES_00,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
	T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no
	version=3.4.2
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id BDC7C1F54E;
	Fri, 26 Aug 2022 18:11:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=80x24.org;
	s=selector1; t=1661537463;
	bh=8XyyPR0bdlBUNrWmLj4Ch+jsnk0xgg1vRStqoq26QU8=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=kY9+o++l6eKgAEiIzg8wCY9fKV1KeCOyEnbzUoDDL3VPMe8dTNq1BHAMoD3lIccID
	 O568Q0UXxkUxnb8OCYUnq+Uwk6s8/odsvJgIMIdKevm9tu6APlr8x0zCcxvvf1tmWS
	 zDB2fOCXcO6OWGGkRK8ujoJDJqStOnQzxQ8jd1MQ=
Date: Fri, 26 Aug 2022 18:11:03 +0000
From: Eric Wong <e@80x24.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: meta@public-inbox.org
Subject: Re: extindex for git? [was: an even bigger git show than before...]
Message-ID: <20220826181103.M706205@dcvr>
References: <20220822023346.938859-1-e@80x24.org>
 <20220822193413.M902704@dcvr>
 <20220825213442.M620858@dcvr>
 <20220826165129.j2p4upnyomhwjpwj@meerkat.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20220826165129.j2p4upnyomhwjpwj@meerkat.local>
List-Id: <meta.public-inbox.org>

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Thu, Aug 25, 2022 at 09:34:42PM +0000, Eric Wong wrote:
> > > I wanted to add search to git repos ages ago, but it was silly
> > > expensive in terms of space.  That was before extindex...
> > > 
> > > extindex ought to be able to offer space savings across forks
> > > and similar documents (commits vs patch mails).
> > > 
> > > At least dfpre/dfpost/dfn/subject may be enough, even...
> > 
> > And I'm also thinking extindexing coderepos can make
> > auto-assocation with inboxes possible.
> > 
> > Right now, configuring coderepos on a large scale is a huge PITA
> > given the M:N associations between inboxes and coderepos.
> > 
> > Being able to do fuzzy JOIN-ish operations based on
> > blobs/filenames/subjects would allow extindex to automatically
> > associate coderepos with inboxes and vice-versa.
> 
> I wonder how well this would work in the presence of many forks? E.g. most of
> the content on git.kernel.org are thin forks of linux.git, so matching by
> blobs/filenames/subjects across all of them would return too many hits and
> some kind of priority ordering would be required, I think.

Auto-grouping of coderepos should be possible by common root commit(s).
Config file ordering will be taken into account, of course;
and that's at the discretion of whoever controls $PI_CONFIG.

> Overall, though, I do agree that this would be really handy.

Yes, it's something I've wanted for years; but couldn't figure
out how to do it efficiently until extindex.