On Thu, Jul 12, 2012 at 03:17:09PM -0700, Douglas Garstang wrote:

> I'm a relative newcomer to git and I've just inherited a setup where
> all of the company's code is in a single git repository. Within this
> repository are multiple projects. It seems that git doesn't natively
> allow cloning/checking out of individual paths within the repo (ie
> projects), which would seem to make integrating git with a continuous
> build system rather difficult. That is, the build system has to clone
> the entire repo, and therefore a change to any project will result in
> the entire contents of the repo being built.
> Correct....?

Yes. The feature you are looking for is either "sparse checkout" (only
check out a subset of the files in the repository databse to the working
tree) or "sparse clone" (only copy a subset of the files into the local
repository database during clone). Git v1.7.0 and later has sparse
checkout (see the "sparse checkout" section in "git help read-tree").
There is no implementation for sparse clone (and not likely to be one
any time soon, as it introduces a lot of complexity into the object
negotiation phase).

The usual advice is that you should break up your big repository into
logical projects. You can do so with git-filter-branch, but beware that
this involves rewriting history, which means a flag day for everybody
switching to the new history (or dealing with migrating commits from the
old history to the new history via rebase).

Finally, if you have a build system which is cloning repeatedly, you may
want to keep a repository on the build server all the time and just
fetch the updates into it. This is much more efficient even if you do
end up paring down your repository.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to