A coding agent rarely solves a real task by completing one isolated file. It has to find the right part of a repository, follow imports and call sites, understand local conventions, make a coordinated change, and check whether the result breaks anything else.
That makes the repository, not the snippet, the useful unit of code data.
This distinction matters when selecting data for model training, retrieval experiments, or evaluation. A very large pile of source files can contain less usable engineering signal than a smaller collection of complete projects with tests, configuration, documentation, and history intact.
What is repository-level code data?
Repository-level code data preserves the relationships that make a software project understandable. At minimum, a useful repository unit includes:
- the source tree and directory structure;
- imports, dependencies, definitions, and call sites;
- tests and test fixtures;
- configuration, schemas, migrations, and build files;
- documentation and setup material; and
- a stable identifier for the project and revision.
Longitudinal repository data adds branches, tags, commits, parent relationships, timestamps, messages, and before-and-after changes. That history shows not only what the finished software looks like, but how engineers changed it.
The difference is practical. An isolated function can support syntax completion. A coherent repository can support cross-file retrieval, change-impact analysis, test generation, patch planning, and issue resolution.
What the research already tells us
Several influential code-model projects point in the same direction.
DeepSeek-Coder used project-level code organization and a fill-in-the-middle objective, reflecting the value of context beyond a single left-to-right file. RepoBench separates repository retrieval, completion with cross-file context, and the combined retrieval-and-completion problem. SWE-bench goes further: it asks a system to resolve real repository issues against a specific base revision and evaluates the resulting patch with tests.
These are different tasks, but they share one requirement: the surrounding project must remain coherent.
If imports no longer resolve, tests have been separated from the code they exercise, or every file comes from an unknown revision, the dataset cannot faithfully represent repository-scale work.
Four kinds of signal a complete repository preserves
1. Cross-file relationships
Real changes propagate. A schema change may require an API update, a migration, a fixture adjustment, and new tests. Repository structure lets a model learn which files belong together and which references matter.
2. Verification context
Tests are not decorative metadata. They encode expected behavior and create a way to distinguish a plausible patch from a correct one. A dataset should report what was actually executed, what only passed static checks, and what could not be reproduced.
3. Local engineering conventions
Projects develop their own naming, abstractions, error patterns, and architectural boundaries. Those conventions are often spread across source, configuration, and documentation. Preserving the project keeps that context available.
4. Temporal signal
Git history exposes sequences that final snapshots hide: a bug and its fix, a refactor across several commits, a revert, a test added after a failure, or the introduction of a new subsystem. These sequences can become training pairs and point-in-time evaluations without manufacturing synthetic changes.
Repository scale does not automatically mean quality
“Complete repository” is a necessary description, not a quality guarantee. A repository can still be dominated by generated code, vendored dependencies, trivial forks, or broken setup material. History can be long but repetitive. A test directory can exist without useful tests.
A credible corpus therefore needs measurements and disclosures at both the package and repository level:
- exact file and line counts with a published counting method;
- language and generated/vendor composition;
- commit, merge, contributor, branch, and tag counts;
- test, documentation, build, and lockfile coverage;
- duplicate detection and disposition;
- secret and personal-data scanning;
- provenance, rights, and permitted-use documentation; and
- checksums that bind the claims to the delivered bytes.
The StarCoder2 and The Stack v2 paper and The Stack v2 dataset card are useful references for provenance, deduplication, governance, and PII handling at large scale. Google's public code-review criteria provide a separate lens for design, functionality, complexity, tests, naming, and documentation.
A concrete example: Gerra Codebase Collection
The Gerra Codebase Collection contains 178 complete repositories packaged as cloneable Git histories rather than loose source snapshots. The July 2026 release records 15,238 unique commit objects, 23,633 current files, 1,379,283 current code lines, and 47,783,501 historical lines across reachable text blobs.
The collection is delivered as prerequisite-free Git bundles with stable pseudonymous IDs, manifests, checksums, sanitization summaries, and audit evidence. A 479 KB full-history sample lets a buyer download, verify, clone, and inspect one complete repository, its 23-commit history, commit index, and five patch pairs before requesting access to the full release.
The sample is intentionally explicit about its boundary: JavaScript syntax and relative imports were statically verified, but runtime tests were not claimed because the exact Hardhat dependency tree and lockfile were unavailable.
That kind of negative statement is part of dataset quality. It distinguishes evidence from inference.
The short answer
Repository-level code data is useful when it preserves the context required to understand and verify a change. For coding agents, that means source plus relationships, tests, environment, and revision history - not merely more tokens of code.
The best evaluation question is simple: can someone clone the unit, locate the relevant context, reproduce the published counts, and tell which claims were actually tested? If the answer is no, the dataset may be large, but it is not yet an inspectable engineering corpus.