Nicheloom

Market intelligence for builders — see what's gaining traction before it's crowded.

Git-lazy-mount mount a repo without cloning it. Works with ordinary Git

Details

External ID
48685386
Source
HN
Company
—
Product
Git-lazy-mount mount a repo without cloning it. Works with ordinary Git
Website domain
github.com
Launched
June 26, 2026
Cohort
—
Upvotes
9
Upvotes percentile
0.5484972677595629
Tags
—
Fetched at
Sept. 7, 2026, 9:26 p.m.
Updated at
Sept. 7, 2026, 9:26 p.m.

Description

Hello!This is an attempt to make google3 style repo clones work with Git. In a HN thread a few days ago the idea sparked for me.It can be super useful for very large repos that need to be cloned for AI coding sessions that might only need a subset of files to accomplish something.Similar to google3, files appear to be there and can be read and edited but they are only fetched when they are needed.It works with normal Git commands so there is no need for a new CLI.On huge catch is, running grep will force fetch all files that grep glob matches. AI coding sessions run the Grep tool quite often. To mitigate this, git-lazy-mount comes with sgrep that offloads grepping to a remote code search engine like SourceGraph.With this, microVMs that run AI sessions can stay lean and start up much faster.I am guessing this is probably faster than baking in the git repo in the image but I have not measured performance of it yet. It is definitely useful if the microVM is spun up with unknown repositories (something like Claude on web).Curious to hear your thoughts and criticismThanks!

Enrichment

Theme
git and repository workflow tools
Vertical
Horizontal
Function
Dev tools
Audience
Developer
AI stance
Not AI
Project type
Hobby / open-source project
Normalized one-liner
mount git repositories without cloning
Manually corrected
False

Could you build this?

No Virtualizing a Git repository via partial lazy mounting mimics enterprise systems like Google's GVFS/EdenFS, requiring deep virtual filesystem (FUSE/VFS) and low-level Git protocol/packfile internals.

What it would actually take: This requires a user-space file system (FUSE or Windows Projected File System) integrated with Git's partial clone and sparse-checkout protocols. The daemon intercepts filesystem read calls, parses remote Git tree objects and commit packs on demand, and populates files lazily with smart caching. Building it requires deep knowledge of OS kernel filesystem interfaces, low-level C/Rust systems programming, and internal Git object storage formats.

Discussion

3 comments analyzed.

Competitors mentioned: git worktrees, sgrep code search backend

Concerns raised: single machine performance compared to worktrees, private repo configuration complexity, unclear applicability to language porting use case

Feature requests: smooth worktree initialization tooling, cloud/multi-VM scaling documentation, language porting workflow support

Competitors

Other products that read as similar to this one — 129 launches clear the similarity bar, closest 8 shown.

Attention rank: #59 of 130 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).

Launched 237 days after the earliest competitor.

Other launches for this product

Same idea, different domain

Nobody's really built a dev tools tool for Sales yet.