4 ms·
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 cl
by webstrand 1y ago
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.
- isaacremuant 1y agoI'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.
- seba_dos1 1y agoAnd they're often (not always) used where subtrees would fit better.
- webstrand 1y agoI 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.
- jonhohle 1y ago> 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).
- webstrand 1y agoYou'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.
- Sophira 1y ago> 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.
- seba_dos1 1y agoYou only get it actually full with "--mirror" switch, but for most use-cases what you get without it is already "full enough".