2 ms·
IIRC there were experimental patches implementing it for git a few months ago. Ironically, to make narrow clones happen, Mercurial is going to change its inter
by glandium 11y ago
IIRC there were experimental patches implementing it for git a few months ago.
Ironically, to make narrow clones happen, Mercurial is going to change its internal structure representing the files in the repository (the manifest) to use a separate manifest for each sub-directory... like git has been doing for trees from day one.
- qznc 11y agoI found patches from 2008, but nothing recent. http://article.gmane.org/gmane.comp.version-control.git/96349/match=narrow+clone http://article.gmane.org/gmane.comp.version-control.git/9634...
- glandium 11y agoYour link is about narrow checkout, not narrow clone (so the .git data is still transfered completely, as opposed to transfered partially). Maybe what I'm thinking about was just a discussion with no formal patch, I don't remember.
- davvid 11y agoThe two features of interest are "shallow clone" and "partial checkout". Both of these features are already part of git. A current experiment is an untracked files cache, which speeds up stuff on large repos considerably. This stuff is actively being worked on -- the git project has always valued performance.
- qznc 11y agoNo, "shallow clone" and "partial checkout" are both different to "narrow clone". Maybe "partial clone" would fit the git terminology better. A shallow clone misses history after a certain point in time (well, commit order). A narrow clone misses history except in a subtree. A partial clone looks like a narrow clone in the workspace, but a narrow clone should have substantially less objects to download and store.