Re: restriction of pulls

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 10, 2007, 14:50 UTC
Message-ID: <Pine.LNX.4.63.0702101533060.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <45CC941E.9030808@dawes.za.net>

Hi,

On Fri, 9 Feb 2007, Rogan Dawes wrote:

Show 12 quoted lines

> Johannes Schindelin wrote:
> > 
> > On Fri, 9 Feb 2007, Christoph Duelli wrote:
> > 
> > > Is it possible to restrict a chechout, clone or a later pull to some 
> > > subdirectory of a repository?
> > 
> > No. In git, a revision really is a revision, and not a group of file 
> > revisions.
> 
> I thought about how this might be implemented, although I'm not entirely 
> sure how efficient this will be.

There are basically three ways I can think of:

- rewrite the commit objects on the fly. You might want to avoid the use 
of the pack protocol here (i.e. use HTTP or FTP transport).

- try to teach git a way to ignore certain missing objects and 
directories. This might be involved, but you could extend upload-pack 
easily with a new extension for that.

(my favourite:)
- use git-split to create a new branch, which only contains doc/. Do work 
only on that branch, and merge into mainline from time to time.

If you don't need the history, you don't need to git-split the branch.

You only need to make sure that the newly created branch is _not_ branched off of mainline, since the next merge would _delete_ all files outside of doc/ (merge would see that the files exist in mainline, and existed in the common ancestor, too, so would think that the files were deleted in the doc branch).

Ciao, Dscho