I've been working on this for a while and wanted to share it.

The problem is simple. Android source trees are over 100GB. If you want to maintain your own custom build, forking those repos to GitHub is basically impossible without LFS. And even with LFS, it's a mess.

So I built a set of shell tools around what I call "git2". The idea is you keep the upstream repo in .git/ as usual, but your own changes live in a separate .git2/ directory. It's like a thin overlay. A typical upstream project might be 2GB, but your overlay tracking just the files you touched is maybe 50KB.

But git2 alone isn't enough when you're dealing with a full Android build. You also need to wire everything together with Android's repo tool and local_manifests system. That's where the rest of the toolkit comes in.

There's a script called make-repo.sh that scans all your git2 overlays, figures out the project names from paths, grabs commit hashes, and spits out a proper default.xml manifest. No hand-editing XML. Another one, git2-all.sh, lets you run push, pull, status, or any git command across every modified project at once. git2-setup.sh finds all projects with a .git2config and initializes them automatically after repo sync. And link-setup.sh handles the symlink mess that Android's build system expects.

On the release side, there are scripts for per-device key generation, signing on tmpfs so keys never touch disk unencrypted, OTA packaging, and a reference update server you can self-host.

The whole thing is demonstrated on GrapheneOS but the approach is generic. Any AOSP-derived project with a massive source tree could use the same overlay and manifest pattern.

Curious what people think. Is the overlay approach better than just maintaining patch files? Anyone doing something similar for large source tree customization?