Repository Operations
Relevant source files
The following files were used as context for generating this wiki page:
Repository operations manage the identification, tracking, and context delivery for software repositories within the oboete system. These operations ensure that memory records (observations, summaries, and prompts) are correctly associated with specific codebases regardless of where they are cloned or how they are accessed.
The system uses a unique repository key derived from Git configuration to unify data across devices. It monitors repository state, such as current branches and uncommitted changes, to provide coding agents with relevant context during active sessions.
Sources: src/repo.rs:1-10, src/consumer/manifest.rs:1-5
Repository Identification and Keys
Oboete identifies repositories using a normalized key derived from the origin remote URL. This ensures that the same repository gets the same key on every device, whether cloned over SSH or HTTPS.
Key Derivation Logic
The identification process follows these steps:
- Search: Find the nearest repository root and Git directory starting from the current working directory.
- Read: Access the
.git/configfile, following any[include]directives up to a depth of 10. - Extract: Identify the
urlvalue within the[remote "origin"]section. - Normalize: Reduce the URL to a
host[:port]/pathformat by dropping schemes, credentials, and trailing.gitsuffixes.
If no origin remote exists or the directory is outside a repository, the system defaults to using the canonicalized filesystem path as the key.
Sources: src/repo.rs:11-150
Repository Key Normalization
The normalization process strips secrets and transport-specific details to create a universal identifier.
| Element | Handling |
|---|---|
| Scheme | Dropped (ssh, https, git, etc.) |
| Credentials | Dropped (username, passwords, tokens) |
| Port | Dropped if default (22, 443, 80, 9418); kept otherwise |
| Host | Converted to lowercase |
| Path | Trimmed of .git and leading/trailing slashes |
Sources: src/repo.rs:152-212
Git State and Status Monitoring
The system retrieves the active state of a repository to inform coding agents about the current work environment. This includes branch names, HEAD SHAs, and porcelain status counts.
Git State Extraction
The git module reads state directly from filesystem files rather than invoking a git process. It identifies:
- Branch: Extracted from
.git/HEADif it points to a ref. - HEAD SHA: Resolved from loose ref files or
packed-refs. - Git Directory: Determined by checking for
.gitdirectories orgitdir:files in linked worktrees.
Sources: src/capture.rs:370-424
Risky State Detection
The manifest consumer identifies "risky" Git states that might affect agent operations. It checks for:
- In-progress operations (rebase, merge, cherry-pick, revert).
- Detached HEAD states.
- Uncommitted changes, merge conflicts, and untracked files using
git status --porcelain=v2.
Sources: src/consumer/manifest.rs:460-555
Git State Flow
This diagram illustrates how repository state is gathered for context injection.
Explanation: The system locates Git metadata on disk and combines it with process output from git status to build a comprehensive view of the repository state.
Sources: src/capture.rs:370-424, src/consumer/manifest.rs:460-555
Repository Scope in Search
Repository operations provide scoping mechanisms for the Memory Control Protocol (MCP) and CLI search tools. Users and agents can limit operations to specific codebases or search globally.
Scope Resolution
The system resolves search scope based on parameters:
- Global: If the
allflag is set, search covers all known repositories. - Targeted: If a repository path or key is provided, search is restricted to that identifier.
- Contextual: By default, search uses the key of the current working directory.
Sources: src/mcp.rs:101-125, src/main.rs:252-258
Database Re-keying
When a repository that was previously identified only by its path gains a remote origin, the system performs a "re-key" operation. This updates existing rows in the database to use the new normalized URL key, ensuring data continuity.
Sources: src/mcp.rs:207-217
Manifest Generation
The manifest provides a high-level summary of repository activity, including recent files touched and active sessions.
Repository-Specific Facts
The manifest consumer processes raw events and stores repository-specific facts in the manifest_facts table.
| Fact Type | Description |
|---|---|
event | General occurrence within the repository |
prompt | User input associated with the codebase |
owner | Directive lines explicitly given by the user |
fail / fixed | Failed tool calls and their subsequent resolutions |
file | Paths of files modified or accessed by tools |
todo | Items extracted from Todo lists or plans |
Sources: src/consumer/manifest.rs:226-270
Manifest Architecture
The following class diagram shows the structure of repository manifest data.
Explanation: The Manifest consumer processes batches of records to populate various manifest parts that describe the current state and history of the repository.
Sources: src/consumer/manifest.rs:17-458
Context Injection
Repository operations culminate in "Injection," where repository-specific context is formatted for a new agent session.
Injection Logic
- Identify: Determine the repository key for the current directory.
- Fetch: Retrieve the latest manifest text, current decisions, and session digests.
- Filter: Exclude the current session from "Other active sessions."
- Format: Combine facts into a Markdown document for the agent.
Sources: src/inject.rs:1-50, src/consumer/manifest.rs:88-120
Conclusion
Repository operations provide the foundational mapping between the physical filesystem and the logical memory of coding agents. By normalizing repository identities and tracking Git state, oboete ensures that context is persistent across clones and relevant to the specific code being edited. This system enables agents to maintain awareness of project decisions, open tasks, and active workstreams across different sessions and devices.
Sources: src/repo.rs:1-10, src/consumer/manifest.rs:1-10, src/inject.rs:1-20