Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-scm
Navigation:
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-scm@g.o
From: "Robin H. Johnson" <robbat2@g.o>
Subject: Re: Splitting gentoo-x86 repository for easier consumption
Date: Sat, 11 Apr 2009 14:21:58 -0700
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 <robbat2@g.o> 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
> capability
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
subtree checkouts.

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
> way.
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.
http://eagain.net/articles/git-for-computer-scientists/

As a caveat, after such time as the blobs are separated from the tree
objects, then it will become partially possible:
http://n2.nabble.com/Git-and-Media-repositories....-td1446700.html
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
does this.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Attachment:
pgpfcJ6FTqmid.pgp (PGP signature)
References:
Splitting gentoo-x86 repository for easier consumption
-- Maciej Mrozowski
Re: Splitting gentoo-x86 repository for easier consumption
-- Robin H. Johnson
Re: Splitting gentoo-x86 repository for easier consumption
-- Caleb Cushing
Re: Splitting gentoo-x86 repository for easier consumption
-- Robin H. Johnson
Re: Splitting gentoo-x86 repository for easier consumption
-- Caleb Cushing
Re: Splitting gentoo-x86 repository for easier consumption
-- Robin H. Johnson
Re: Splitting gentoo-x86 repository for easier consumption
-- Caleb Cushing
Navigation:
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Splitting gentoo-x86 repository for easier consumption
Next by thread:
Re: Splitting gentoo-x86 repository for easier consumption
Previous by date:
Re: Splitting gentoo-x86 repository for easier consumption
Next by date:
Re: Status report, 2009/04/10


Updated Jun 17, 2009

Summary: Archive of the gentoo-scm mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.