docs(capabilities/github): suggest shallow clones to optimize git speed#112
Open
dembrane-sam-bot wants to merge 2 commits into
Open
docs(capabilities/github): suggest shallow clones to optimize git speed#112dembrane-sam-bot wants to merge 2 commits into
dembrane-sam-bot wants to merge 2 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this change?
Adds explicit guidance to
src/capabilities/github.mdsuggesting the use of shallow clones (git clone --depth 1) when cloning large external repositories (likeecho) under/tmp/when full history is not required. It adds a load-bearing caveat that a full clone is still appropriate when history is required (e.g. forgit logor blame queries required by our "Curiosity over guessing" rule).What did Sam notice that led to this?
In yesterday's tool-calls audit log, a full
git cloneof the largeDembrane/echorepository in session808498e5b625took 265 seconds. This is extremely slow and close to our tool timeout limit of 300 seconds. While this was a single slow-but-successful occurrence (not yet a repeating multi-session pattern), suggesting a shallow clone as a scoped optimization for single-file tasks helps prevent potential timeouts.Tier?
Tier 1 (capability modification).
Confidence?
100% confident this is a safe, simple, and honest doc improvement that will optimize git operations while preserving our core curiosity rules.