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

[Jeff King <peff@peff.net>]

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

> 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