Re: extindex for git? [was: an even bigger git show than before...]

[Eric Wong <e@80x24.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.