Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's a little more complex than that. Yes git can work in a peer-to-peer fashion, but the porcelain is definitely set up for a hub-and-spoke model, given how cloning a remote repo only gives you a partial copy of the remote history.

There's other stuff too, like git submodules can't be configured to reference another branch on the local repository and then be cloned correctly, only another remote.





> given how cloning a remote repo only gives you a partial copy of the remote history

When you clone you get the full remote history and all remote branches (by default). That’s painfully true when you have a repo with large binary blobs (and the reason git-lfs and others exist).


You're right, I got that part wrong, git actually fetches all of the remote commits (but not all of the refs, many things are missing, for instance notes).

But a clone of your clone is not going to work the same way, since remote branches are not cloned by default, either. So it'll only have partial history. This is what I was thinking about.


Notes aren't refs.

Yes they are, they get put in /refs/notes?

    git fetch origin refs/notes/*:refs/notes/*
is the command you have to run to actually clone remote refs if you're making a working-copy clone?

You're right. Thank you for the correction.

> given how cloning a remote repo only gives you a partial copy of the remote history

You may be thinking of the optional -depth switch, which allows you to create shallow clones that don't have the full history. If you don't include that, you'll get the full history when cloning.


You only get it actually full with "--mirror" switch, but for most use-cases what you get without it is already "full enough".

I'd say git submodules have such an awkward UX that should probably not be used except in very rare and organized cases. I've done it before but it has to be worth it.

But I get your larger point.


And they're often (not always) used where subtrees would fit better.

I can't get over my fear of subtrees after accidentally nuking one of my repos by doing a rebase across the subtree commit. I've found that using worktrees, with a script in the main branch to set up the worktrees, works pretty well to split history across multiple branches, like what you might want in a monorepo.

Sadly doing a monorepo this way with pnpm doesn't work, since pnpm doesn't enforce package version requirements inside of a pnpm workspace. And it doesn't record installed version information for linked packages either.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: