git.clone action is one of the most fundamental building blocks in Overcut workflows. It allows you to clone Git repositories into the workflow execution environment, providing agents and subsequent steps with access to your source code for analysis, modification, or review. With advanced multi-repository support, you can dynamically clone multiple repositories based on intelligent identification or clone them explicitly.
Overview
Thegit.clone action performs Git clone operations with intelligent caching, branch management, and advanced clone options. It supports both single and multi-repository workflows, with seamless integration with the repo.identify action for dynamic repository selection.
Multi-Repository Support
Clone multiple repositories in a single step, either from dynamic identification or explicit specification.
Dynamic Chaining
Seamlessly chain with repo.identify to automatically clone all relevant repositories for your workflow context.
Smart Caching
Automatically uses cached repositories when possible, dramatically reducing clone time for subsequent runs.
Advanced Options
Support for shallow clones, sparse checkouts, partial clones, and more Git optimization features.
Multi-Repository Workflows
Dynamic Repository Cloning
The most powerful pattern combinesrepo.identify with git.clone to automatically clone all relevant repositories:
Single Repository from Identification
Clone only the top-ranked repository from identification:Basic Usage
Simple Repository Clone
The most basic usage clones a repository using its default branch:Clone Specific Branch
Clone a specific branch instead of the default:Using Dynamic Values
Reference values from the trigger or previous steps:Parameters
Required Parameters
Repository specification that can be:
- Single repository:
"owner/repo" - Dynamic from identification:
"{\{outputs.identify-repos\}}"(clones all identified repositories) - Specific from identification:
"{\{outputs.identify-repos.[0].repoFullName\}}"(clones first identified repository) - Trigger-based:
"{\{trigger.repository.fullName\}}"
Optional Parameters
Specific branch to checkout. If not specified, the repository’s default branch will be used. Can use template expressions like
"{{trigger.pullRequest.headBranch}}".Advanced Git clone configuration options for fine-grained control over the clone operation.
Clone Options
ThecloneOptions parameter provides fine-grained control over the clone operation:
Depth Control
Limit the clone depth for faster downloads:1: Latest commit only (fastest, minimal history)0: Full history (slowest, most disk usage)- Any positive integer for custom depth
Single Branch Clone
Clone only the specified branch to reduce download size:Sparse Checkout
Clone only specific directories or files:Cache Incompatibility: Sparse checkout forces a full clone and cannot use repository caching, as it fundamentally changes the repository structure. This means every run will perform a fresh clone, which may be slower but ensures the correct file structure for your workflow.
- Faster downloads for large repositories
- Reduced disk space usage
- Focus on relevant code sections
- Ideal for monorepos or large projects
Partial Clone Filters
Use Git’s partial clone feature to skip large files:"blob:none": Skip all file contents (fastest, metadata only)"blob:limit=100M": Skip files larger than 100MB"combine": Apply multiple filters together
Force Fresh Clone
Bypass cache and force a fresh clone:ignoreCache:
- Debugging cache-related issues
- Testing with fresh dependencies
- Ensuring latest code changes
- Troubleshooting workflow problems
Complete Examples
Code Review Workflow
Clone a repository for code review with optimization:Cross-Repository Bug Investigation
Investigate a bug that might span multiple repositories:Documentation Generation Across Repositories
Generate documentation from multiple related repositories:Output and Context
Single Repository Output
For single repository clones, the output structure is:Full path to the cloned repository in the workspace.
Whether the repository was loaded from cache (true) or freshly cloned (false).
Whether dependencies are already installed in the cached repository.
Multi-Repository Output
For multi-repository clones (when using{{outputs.identify-repos}}), the output structure includes:
Overall success status. True if all repositories cloned successfully, false if any failed.
Array of individual repository clone results.
Full name of the repository that was cloned.
Full path to this repository in the workspace.
Whether this repository was loaded from cache.
Whether this specific repository clone was successful.
Error message if the repository clone failed.
Summary statistics for the multi-repository clone operation.
Total number of repositories attempted.
Number of repositories successfully cloned.
Number of repositories that failed to clone.
Number of repositories loaded from cache.
Available Variables
Use these variables in subsequent steps: Single Repository:{{outputs.clone-repo.workspacePath}}: Full path to the cloned repository{{outputs.clone-repo.fromCache}}: Whether cache was used{{outputs.clone-repo.dependenciesInstalledOnCache}}: Whether dependencies are already installed
{{outputs.clone-repos.success}}: Overall clone success status{{outputs.clone-repos.repositories}}: Array of all repository results{{outputs.clone-repos.summary.successful}}: Count of successful clones{{outputs.clone-repos.summary.failed}}: Count of failed clones
Repository Context
All cloned repositories are automatically added to the workflow context and available to agents:- Repository Information: Name, provider, organization
- File System Access: Full read/write access to repository contents
- Git Operations: Access to commit history, branches, and Git metadata
- Dependency Management: Automatic detection and installation of dependencies (when caching is enabled)
Error Handling
Partial Success in Multi-Repository Clones
When cloning multiple repositories, some may succeed while others fail. The action handles this gracefully:Workflow Continuation Strategies
Handle clone failures gracefully in your workflows:Caching Behavior
Automatic Cache Usage
Overcut automatically uses cached repositories when possible:- Cache Eligibility: Determined by clone options and repository configuration
- Cache Refresh: Automatic background refresh every 10 days
- Cache Invalidation: Stale caches (20+ days) are ignored
- Non-blocking: Cache operations never block workflow execution
- Multi-Repository: Each repository in a multi-repo clone is cached independently
Cache Compatibility
| Clone Option | Cache Compatible |
|---|---|
depth | ✅ Yes |
singleBranch | ✅ Yes |
filter | ✅ Yes |
sparseCheckout | ❌ No |
ignoreCache: true | ❌ No |
Cache Performance
- First Run: Normal clone time (creates cache for each repository)
- Subsequent Runs: 90%+ faster using cache
- Cache Hit Rate: Typically 95%+ for active repositories
- Multi-Repository: Cache hits are independent per repository
- Background Refresh: Automatic updates without blocking workflows
Best Practices
Dynamic Repository Selection
- Use
repo.identifyfirst: Always identify repositories dynamically rather than hardcoding - Set appropriate confidence thresholds: Use
minConfidence: 0.7+for critical operations - Provide identification hints: Help the AI make better repository selections
- Handle partial failures: Design workflows to continue even if some repositories fail to clone
Performance Optimization
- Use shallow clones: Set
depth: 1for faster clones when full history isn’t needed - Enable single branch: Use
singleBranch: trueto reduce download size - Leverage caching: Avoid
ignoreCache: trueunless necessary - Filter large files: Use
filteroptions for repositories with large binary files
Multi-Repository Workflows
- Clone in parallel: The action automatically clones multiple repositories in parallel for better performance
- Check success status: Always verify
{{outputs.clone-repos.success}}before proceeding - Use summary statistics: Leverage
{{outputs.clone-repos.summary}}for workflow decisions - Handle individual failures: Design agents to work with partial repository sets
Template Usage
- Use full output for multi-repo:
{{outputs.identify-repos}}for all identified repositories - Use indexed access for single repo:
{{outputs.identify-repos.[0].repoFullName}}for just the top result - Combine with conditionals: Use template logic to handle different scenarios
- Pass context to agents: Include repository information in agent instructions