| 1 |
On Sat, Apr 11, 2009 at 04:59:53PM -0400, Caleb Cushing wrote: |
| 2 |
> On Sat, Apr 11, 2009 at 2:09 PM, Robin H. Johnson <robbat2@g.o> wrote: |
| 3 |
> > Narrow is already possible in both CVS and SVN, but it is not natively |
| 4 |
> > in Git, which is the reason that it's been a TODO item for them (you can |
| 5 |
> > get it with the git-cvsserver already, but they want it natively), and |
| 6 |
> > that I mentioned the GSoC project on their side. |
| 7 |
> the problem in communication is that you are using svn/cvs terminology |
| 8 |
> to describe git, in git checkout does not imply fetch it does imply it |
| 9 |
> in svn I believe. there is a shallow clone in git and narrow |
| 10 |
> capability |
| 11 |
No, that shallow/narrow is the upstream Git terminology, I just used it |
| 12 |
for SVN/CVS as well. In SVN/CVS, narrow is more commonly known as |
| 13 |
subtree checkouts. |
| 14 |
|
| 15 |
Git has shallow (partial history). It does not have narrow/sparse. |
| 16 |
CVS/SVN have narrow/sparse, and are strictly shallow by design. |
| 17 |
|
| 18 |
> the problem is there is no way to update a shallow clone in a shallow |
| 19 |
> way. |
| 20 |
In Git, doing a shallow fetch as an update of any repo, shallow or not, |
| 21 |
it conceptually impossible. This is because the tree objects exist as a |
| 22 |
directed graph, and you CANNOT have two seperate digraphs with links in |
| 23 |
the middle not existing. |
| 24 |
http://eagain.net/articles/git-for-computer-scientists/ |
| 25 |
|
| 26 |
As a caveat, after such time as the blobs are separated from the tree |
| 27 |
objects, then it will become partially possible: |
| 28 |
http://n2.nabble.com/Git-and-Media-repositories....-td1446700.html |
| 29 |
This work proposed making it possible to have placeholder blobs, that |
| 30 |
merely represent their content, but do not actually contain it. |
| 31 |
|
| 32 |
> if you were to host a git repo on nfs (or other network mountable fs) |
| 33 |
> you could eve clone it locally in an as shallow way as cvs by using |
| 34 |
> git-new-workdir but that would basically be a hack... |
| 35 |
If you have it locally, you can go one step beyond this, and use shared |
| 36 |
references (which is the proper way), and not have any content (packs or |
| 37 |
objects) at all in your local .git directory. The latest git.eclass now |
| 38 |
does this. |
| 39 |
|
| 40 |
-- |
| 41 |
Robin Hugh Johnson |
| 42 |
Gentoo Linux Developer & Infra Guy |
| 43 |
E-Mail : robbat2@g.o |
| 44 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |
Archives