indexer: handle missing parent objects in shallow clones and root commits#21
Conversation
…mits When `semcode-index --source` is run without `--git`, it auto-detects HEAD and constructs the range `HEAD^..HEAD`. On a shallow clone or a repo initialized from a tarball (single root commit), `HEAD^` refers to a parent object that doesn't exist in the local object store, causing gix to error with "An object with id ... could not be found". Fix `list_shas_in_range` to catch this error and fall back to returning just the target commit SHA, so indexing proceeds normally with the single HEAD commit. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
|
Hi @Vui-Chee! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
Problem
Running
semcode-index --source /path/to/repowithout--gitfails with:This happens on:
git clone --depth 1) — the HEAD commit has parent SHAs recorded in it, but those parent objects are not present in the local object storegit init && git add . && git commit) with no parent at allRoot Cause
When no
--gitflag is provided,run_pipelineauto-detects HEAD and constructs the rangeSHA^..SHA(parent-to-HEAD).list_shas_in_rangethen callsresolve_to_commit(repo, "SHA^"), which gix implements by looking up the parent object in the local store — failing with the above error when it doesn't exist.Fix
In
list_shas_in_range, catch the error from resolvingfrom_specand fall back to returning just[to_commit_sha]. This means indexing proceeds with the single HEAD commit, which is the correct behaviour for the auto-detect case.Test