Re: [PATCH WIP 0/3] git log --exclude

From: Jeff King <peff@peff.net>
Date: Oct 6, 2011, 14:34 UTC
Message-ID: <20111006143441.GA21558@sigill.intra.peff.net>
In-Reply-To: <7vhb3n8ie9.fsf@alter.siamese.dyndns.org>

On Wed, Oct 05, 2011 at 10:20:30AM -0700, Junio C Hamano wrote:

Show 18 quoted lines

> The way I envisioned the narrow cloning would work like this [*1*]:
> 
>  * The narrowed set of paths is an attribute of the local repository. It
>    is not tied to the history nor the current working tree state, so the
>    information does not live in the index or in the history. A new file
>    $GIT_DIR/narrowed-paths specifies a list of pathspecs. We call a
>    repository with such a file "a narrowed repository".
> 
>  * The objects that live in a narrowed repository are subset of the
>    objects in an unnarrowed repository that records the same
>    history. Objects are not modified in any way when transferring into
>    a narrowed repository. E.g. if you clone git.git but limit the tree to
>    Documentation/ and builtin/, you will get _all_ commit objects, even
>    the ones that do _not_ touch these two directories, and the top level
>    tree objects. These top level tree objects _do_ record the object names
>    for paths outside the narrowed area. To facilitate local history
>    traversal, we may add either grafts or replace entries to "gather" away
>    commits that do not touch the narrowed area, but this is not essential.

I'm really just a bystander on this topic, and haven't given it too much thought. But one stumbling block I see for narrow clone is how narrow repositories will interact with object transfer from other repositories.

For example, if I have a narrow git.git that omits Documentation, and I do a "git fetch" from a non-narrow repository, then how do we tell the non-narrow remote that we don't have blobs in Documentation, and that they should not be used as delta bases for any objects that are sent?

The current protocol relies on certain repository properties on the remote end that narrow clone will violate. I don't see a way around that without a protocol extension to communicate the narrowness. What will that extension look like?

-Peff