You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a marketplace plugin uses a github source with a path inside a larger repo, copilot plugin install
runs git clone --depth 1 --progress --branch <ref> <url> <cache>/marketplaces/<owner>--<repo> with Git LFS
smudge turned on. Every LFS-tracked file in the repo gets downloaded, including files far outside the
plugin's path. If any one of those objects can't be fetched (for example batch response: Not Found
for an object that was pushed late or never pushed), checkout fails and the install is aborted:
The plugin directory itself contains no LFS files and is about 1.2 MB, but the install downloads about
223 MB of pack data plus every LFS object in the repo, and then fails.
Affected version
Observed on Windows; the clone command is unchanged as of GitHub Copilot CLI 1.0.88.
Steps to reproduce the behavior
Register a marketplace plugin with {"source":"github","repo":"<owner>/<repo>","path":"plugins/<name>","ref":"main"}
where the repo tracks unrelated files with Git LFS (<data-dir>/** filter=lfs).
Make one LFS object under <data-dir> unavailable on the server (or just use a large LFS data set).
Run copilot plugin install <name>@<marketplace>.
The install downloads all LFS content, then fails at checkout with smudge filter lfs failed.
Expected behavior
The plugin fetch shouldn't run the LFS smudge for content outside the plugin path. At minimum,
set GIT_LFS_SKIP_SMUDGE=1 for the clone, then git lfs pull --include "<path>/**" only when the
plugin path actually contains LFS pointers.
A failure to download content outside the plugin path shouldn't fail the install.
Workaround: set GIT_LFS_SKIP_SMUDGE=1 before copilot plugin install, and delete the half-cloned marketplaces/<owner>--<repo> directory first.
Related: the cache directory is keyed only by <owner>--<repo>. Two plugins from the same repo on
different refs look like they share one checkout, so the cache key should probably include the ref.
OS: Windows 11 (also affects macOS/Linux, because the clone behavior is the same)
Describe the bug
When a marketplace plugin uses a
githubsource with apathinside a larger repo,copilot plugin installruns
git clone --depth 1 --progress --branch <ref> <url> <cache>/marketplaces/<owner>--<repo>with Git LFSsmudge turned on. Every LFS-tracked file in the repo gets downloaded, including files far outside the
plugin's
path. If any one of those objects can't be fetched (for examplebatch response: Not Foundfor an object that was pushed late or never pushed), checkout fails and the install is aborted:
The plugin directory itself contains no LFS files and is about 1.2 MB, but the install downloads about
223 MB of pack data plus every LFS object in the repo, and then fails.
Affected version
Observed on Windows; the clone command is unchanged as of GitHub Copilot CLI 1.0.88.
Steps to reproduce the behavior
{"source":"github","repo":"<owner>/<repo>","path":"plugins/<name>","ref":"main"}where the repo tracks unrelated files with Git LFS (
<data-dir>/** filter=lfs).<data-dir>unavailable on the server (or just use a large LFS data set).copilot plugin install <name>@<marketplace>.smudge filter lfs failed.Expected behavior
path. At minimum,set
GIT_LFS_SKIP_SMUDGE=1for the clone, thengit lfs pull --include "<path>/**"only when theplugin path actually contains LFS pointers.
pathshouldn't fail the install.path([FEATURE] Use sparse checkout for plugin installs — only fetch shipping assets, not entire repo #2399), so only the plugin's files are downloaded.Additional context
GIT_LFS_SKIP_SMUDGE=1beforecopilot plugin install, and delete the half-clonedmarketplaces/<owner>--<repo>directory first.<owner>--<repo>. Two plugins from the same repo ondifferent
refs look like they share one checkout, so the cache key should probably include the ref.