Working with Massive Git Repositories When Disk Space is Limited

Posted on August 21, 2025

Hey there!

So, you want to contribute to the Linux kernel or Chromium, but your laptop only has 256GB of storage and you can't afford to download 30GB+ of git history? I've been there!

In this post, I'll show you how to work with massive repositories when disk space is at a premium. We'll focus on real-world examples like the Linux kernel and Chromium, and explore practical strategies that actually work.

The Problem: Massive Repository Sizes

Let's start with some eye-opening numbers:

Repository Size Examples

• Linux kernel: ~1.5GB+ (full history)
• Chromium: ~30GB+ (full history)
• Large monorepos: Can exceed 50GB+
• Your typical laptop: 256GB total storage

When you try to do a full clone of Chromium, you're essentially downloading a small operating system worth of data. That's not practical for most developers!

Real-World Scenario: Contributing to Linux Kernel

Let me walk you through a real scenario I encountered when trying to contribute a small fix to the Linux kernel:

The Challenge

# This would download ~1.5GB of data
git clone https://github.com/torvalds/linux.git
cd linux
# Now you have the full history, but it took forever and used tons of space

The Solution: Minimal Working Clone

# Clone with minimal depth and single branch
git clone --depth 1 --single-branch --branch main https://github.com/torvalds/linux.git
cd linux

# Check what we actually got
du -sh .git
# Output: ~50MB instead of ~1.5GB

git log --oneline
# Output: Just the latest commit

Making Your Changes

# Edit the file you need to fix
vim drivers/net/ethernet/example.c

# Check your changes
git diff

# Stage and commit
git add drivers/net/ethernet/example.c
git commit -m "Fix ethernet driver issue"

# Create a patch file (this is how Linux kernel contributions work)
git format-patch HEAD~1
# Creates: 0001-Fix-ethernet-driver-issue.patch

Contributing via Patch

The Linux kernel community actually prefers patch files! You can:

1. Email the patch to the maintainer
2. Upload it to the kernel mailing list
3. Submit it via the kernel.org web interface

# The patch file contains everything needed
cat 0001-Fix-ethernet-driver-issue.patch
# Shows: commit message, author info, and diff

Chromium: The Ultimate Challenge

Chromium is even more challenging - it's essentially a complete browser engine:

The Numbers

• Full clone: ~30GB
• Shallow clone: ~2GB
• Your laptop storage: 256GB (and you need space for other things!)

Strategy 1: Web-Based Workflow

For simple changes, avoid local cloning entirely:

1. Fork Chromium on GitHub
2. Navigate to the file you want to change
3. Click the pencil icon to edit directly in the browser
4. Make your changes in the web editor
5. Commit and create pull request through GitHub's interface

This approach uses zero local disk space!

Strategy 2: Minimal Local Clone

For more complex changes:

# Clone only what you need
git clone --depth 1 --single-branch --branch main https://chromium.googlesource.com/chromium/src.git
cd src

# Check disk usage
du -sh .git
# Output: ~2GB instead of ~30GB

# Work on your specific component
cd components/your-component
vim your-file.cc

# Commit your changes
git add components/your-component/your-file.cc
git commit -m "Fix component issue"

# Push to your fork
git push origin main

Advanced Strategies for Massive Repositories

Strategy 1: Selective History Fetch

When you need some context but not everything:

# Get only recent commits (last 100)
git fetch --depth 100 origin main

# Get commits from specific date
git fetch --shallow-since="2024-01-01" origin main

# Get specific branch with limited depth
git fetch --depth 10 origin feature-branch

Strategy 2: Component-Based Cloning

Some massive projects support partial cloning:

# Clone only specific subdirectories (if supported)
git clone --depth 1 --filter=blob:none --sparse https://github.com/massive/project.git
cd project
git sparse-checkout init --cone
git sparse-checkout set components/your-component

Strategy 3: Patch-Based Contribution

The most disk-efficient approach:

# Create minimal clone
git clone --depth 1 https://github.com/massive/project.git
cd project

# Make your changes
vim src/your-file.cpp
git add src/your-file.cpp
git commit -m "Fix critical bug"

# Create patch file
git format-patch HEAD~1
# Creates: 0001-Fix-critical-bug.patch

# Share the patch (email, issue, etc.)
# Others can apply: git apply 0001-Fix-critical-bug.patch

Disk Space Management Tips

Before You Start

# Check available disk space
df -h

# Check current directory size
du -sh .

# Estimate repository size (check GitHub/GitLab)
# Most large repos show size on their homepage

Repository Size Guidelines

• < 100MB: Safe to use git fetch --unshallow
• 100MB - 1GB: Consider selective fetch or branch workflow
• > 1GB: Use shallow clone + branch workflow
• > 10GB: Web-based workflow or patch-based contribution

Cleanup Commands

# Clean up git objects
git gc --prune=now

# Remove stale remote references
git remote prune origin

# Check what's taking space
du -sh .git/objects

Real-World Examples

Example 1: Linux Kernel Bug Fix

# Minimal clone
git clone --depth 1 --single-branch https://github.com/torvalds/linux.git
cd linux

# Fix a small bug in a driver
vim drivers/net/ethernet/realtek/r8169.c
# Change one line to fix the issue

# Create patch
git add drivers/net/ethernet/realtek/r8169.c
git commit -m "Fix r8169 driver compatibility issue"
git format-patch HEAD~1

# Result: 0001-Fix-r8169-driver-compatibility-issue.patch
# Size: ~2KB instead of downloading 1.5GB

Example 2: Chromium Documentation Update

# Web-based approach (zero local space)
# 1. Go to https://github.com/chromium/chromium
# 2. Navigate to docs/your-file.md
# 3. Click edit button
# 4. Make changes in browser
# 5. Commit and create PR

# Alternative: Minimal local clone
git clone --depth 1 --single-branch https://chromium.googlesource.com/chromium/src.git
cd src
vim docs/your-file.md
git add docs/your-file.md
git commit -m "Update documentation"
git push origin main

Troubleshooting Common Issues

Issue: "No space left on device"

# Error: fatal: write error: No space left on device
git fetch --unshallow

Solutions:

1. Use web-based editing instead
2. Create patch files and share them
3. Push to new branch without fetching history
4. Use selective fetch with limited depth

Issue: "Shallow update not allowed"

# Error: Shallow update not allowed
git push origin main

Solutions:

1. Push to new branch: git push origin your-branch
2. Create pull request from the branch
3. Use patch workflow: git format-patch HEAD~1

The Takeaway

Working with massive repositories doesn't have to mean downloading gigabytes of data. The key strategies are:

1. Web-based workflow - Use GitHub's editor for simple changes
2. Minimal clones - Use --depth 1 and --single-branch
3. Patch-based contribution - Create and share patch files
4. Selective fetching - Get only the history you need
5. Component-based cloning - Clone only what you're working on

These approaches let you contribute to projects like Linux kernel and Chromium even with limited disk space. The communities actually prefer some of these methods (like patch files for Linux kernel)!

Remember: You don't need the full history to make meaningful contributions. Focus on your specific changes and use the right tools for the job.

Happy contributing!

---

P.S. If you're interested in more git workflows, check out my post about working with git shallow clones for the complete workflow from clone to push.