Proposal: Extension Point for Pluggable Repository Storage Backends in EGit**

[carstenartur]

Summary

I would like to propose the addition of an extension point in EGit that allows third-party plugins to contribute alternative JGit Repository implementations — specifically to enable database-backed storage layers that run alongside EGit's default FileRepository.

Background & Motivation

I maintain the Eclipse Sandbox project, which includes two modules relevant to this discussion:

1. sandbox-jgit-storage-hibernate — A complete JGit storage backend that stores Git objects, refs, pack data, and reflogs in a relational database via Hibernate ORM. The implementation (HibernateRepository) extends DfsRepository and provides HibernateObjDatabase, HibernateRefDatabase, and HibernateReflogWriter. It also offers a GitDatabaseQueryService with full-text search (via Hibernate Search / Lucene) for commit messages, file paths, Java type hierarchies, annotations, symbols, and even semantic/hybrid vector search.

2. sandbox_extra_search — An Eclipse plugin that provides advanced search views (commit search, type history, commit analytics) intended to work within the Eclipse IDE alongside EGit.

The goal is to install sandbox_extra_search as a companion plugin to EGit so that whenever EGit performs Git operations (clone, fetch, commit, push), the data is simultaneously indexed into the database layer. This would unlock powerful queries that are impossible with filesystem-based Git storage alone — for example:

• Full-text search across all commit messages in a repository
• "Which commits touched this Java type?" (type change history)
• Author statistics and commit analytics
• Annotation change tracking across versions
• Semantic code search using embeddings

The Problem: No Way to Plug In

Currently, EGit hardcodes FileRepository as the only repository type:

• RepositoryCache.open() always produces FileRepository instances
• There is no extension point (e.g., org.eclipse.egit.core.repositoryProvider) that would allow a plugin to contribute an alternative Repository implementation or to wrap/decorate the repository lifecycle
• HibernateRepository extends DfsRepository, which is a completely different class hierarchy from FileRepository — they share the Repository base class but diverge below that

This means my plugin cannot transparently redirect or mirror EGit's data layer to the database. The only workaround I have found so far is a "parallel index" approach:

EGit commit/pull → IResourceChangeListener → detect .git changes → IncrementalIndexer → HSQLDB + Lucene

While this works for read-only indexing (listening to EGit events and independently walking the Git history), it has significant limitations:

• Delayed and redundant: EGit already reads all the Git objects during its operations. The parallel indexer has to re-read them independently, wasting I/O and time.
• No transactional consistency: The database index can fall out of sync with the actual Git state because the indexing happens asynchronously via resource change events.
• No write-path integration: The database layer cannot participate in Git write operations (e.g., writing objects during commit or fetch).
• No deep integration possible: Features like "show database-backed reflog" or "query commit metadata from DB instead of walking RevWalk" cannot be offered because EGit always uses its own FileRepository.

Technical Proposal

I propose an extension point mechanism that would allow plugins to participate in the repository lifecycle. There are several possible approaches, ranging from minimal to comprehensive:

Option A: Repository Lifecycle Listener (Minimal)

An extension point like org.eclipse.egit.core.repositoryLifecycleListener that is notified whenever EGit opens, connects, or disconnects a repository:

public interface IRepositoryLifecycleListener {
    /** Called after a Repository has been opened/connected by EGit. */
    void repositoryOpened(Repository repository, IProject project);

    /** Called before a Repository is disconnected/closed. */
    void repositoryClosing(Repository repository);
}

This would allow companion plugins to set up their own data structures (database indexes, caches) in sync with EGit's repository lifecycle, without needing to discover repositories independently.

Option B: Repository Decorator / Wrapper (Medium)

An extension point that allows wrapping the Repository object returned by RepositoryCache:

public interface IRepositoryDecorator {
    /**
     * Wrap or decorate the repository.
     * Return the original repository if no decoration is needed.
     */
    Repository decorate(Repository repository);
}

This would allow a plugin to intercept reads/writes by wrapping the ObjectDatabase, RefDatabase, etc. with decorating implementations that mirror data to a secondary store.

Option C: Pluggable Storage Backend via RepositoryBuilder (Comprehensive)

An extension point that contributes a RepositoryBuilder factory, allowing EGit to use alternative Repository implementations entirely:

public interface IRepositoryBuilderFactory {
    /** 
     * Priority for ordering multiple factories.
     */
    int getPriority();

    /**
     * Whether this factory can handle the given Git directory.
     */
    boolean canHandle(File gitDir);

    /**
     * Create a Repository for the given Git directory.
     */
    Repository open(File gitDir) throws IOException;
}

This would allow a plugin to say "for this repository, use HibernateRepository instead of FileRepository" — enabling a complete storage backend swap.

What I Am NOT Proposing

• I am not proposing changes to JGit itself (JGit already has the DfsRepository abstraction)
• I am not proposing to replace EGit's default behavior — the extension point should be optional, with FileRepository remaining the default when no extensions are contributed
• I am not proposing to break any existing API contracts

Prior Art

• JGit already supports pluggable backends via the DfsRepository / DfsObjDatabase abstraction — Gerrit's in-memory repositories use this. EGit simply does not expose this flexibility.
• Eclipse Platform has extension points for virtually every subsystem (builders, natures, resource listeners, team providers). A storage-layer extension point for EGit would be consistent with this pattern.
• NetBeans and IntelliJ both allow plugins to contribute VCS backend customizations at the storage level.

I have a working JGit DFS backend (HibernateRepository with full ObjDatabase, RefDatabase, ReflogReader/Writer implementations) and an Eclipse plugin that already integrates with EGit at the IResourceChangeListener level.

I would appreciate feedback on:

1. Is this a use case the EGit team would consider supporting?
2. Which of the three options (A, B, or C) would be most palatable?
3. Are there architectural concerns I should be aware of? (e.g., RepositoryCache assumptions, thread safety, performance)

Thank you for your time!

— Carsten Hammer
sandbox project