On Sat, Apr 11, 2009 at 04:59:53PM -0400, Caleb Cushing wrote:
> On Sat, Apr 11, 2009 at 2:09 PM, Robin H. Johnson <email@example.com> wrote:
> > Narrow is already possible in both CVS and SVN, but it is not natively
> > in Git, which is the reason that it's been a TODO item for them (you can
> > get it with the git-cvsserver already, but they want it natively), and
> > that I mentioned the GSoC project on their side.
> the problem in communication is that you are using svn/cvs terminology
> to describe git, in git checkout does not imply fetch it does imply it
> in svn I believe. there is a shallow clone in git and narrow
No, that shallow/narrow is the upstream Git terminology, I just used it
for SVN/CVS as well. In SVN/CVS, narrow is more commonly known as
Git has shallow (partial history). It does not have narrow/sparse.
CVS/SVN have narrow/sparse, and are strictly shallow by design.
> the problem is there is no way to update a shallow clone in a shallow
In Git, doing a shallow fetch as an update of any repo, shallow or not,
it conceptually impossible. This is because the tree objects exist as a
directed graph, and you CANNOT have two seperate digraphs with links in
the middle not existing.
As a caveat, after such time as the blobs are separated from the tree
objects, then it will become partially possible:
This work proposed making it possible to have placeholder blobs, that
merely represent their content, but do not actually contain it.
> if you were to host a git repo on nfs (or other network mountable fs)
> you could eve clone it locally in an as shallow way as cvs by using
> git-new-workdir but that would basically be a hack...
If you have it locally, you can go one step beyond this, and use shared
references (which is the proper way), and not have any content (packs or
objects) at all in your local .git directory. The latest git.eclass now
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : firstname.lastname@example.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85