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

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

I really do not want to see the exclude patterns nor mechanism used for this. This will unnecessarily impact the long term design of narrow clones I had in mind.

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.

 * "struct pathspec" gains a handful of new fields to carry the set of
   narrowing pathspecs taken from $GIT_DIR/narrowed-paths file down the
   callchain. When we decide to see if a given path matches the pathspec
   and/or is worth descending into, we use these pathspecs to reject
   anything that is outside of the narrowed area before applying user
   supplied pathspec. We use narrowing pathspecs even for the whole tree
   operation.

 * "fsck", "prune" and friends that do not use user-supplied pathspec will
   learn the narrowed-paths so that the tree entries that describe objects
   outside the narrowed area (e.g. "Makefile" in the top-level tree in a
   repository narrowed to "Documentation/" and "builtin/") are ignored.

   I looked at fsck and unpack-objects (surprise, but it does seem to need
   some work) a few months ago for this exact purpose, and it appeared
   doable.

We may want to be able to say something like "I want Documentation/ but not Documentaion/howto/", and for that to work, narrowed-paths needs to be able to express negative matches. And in _that_ context, we will need negative pathspec matches (and I think during the last round of pathspec updates we identified where the support for ":(no):pathspec" needs to be added in the codepath).

You could say "Use pathspec for inclusion and ignore patterns for exclusion", but I do not think that inconsistency has merits.

For the purpose of "log --exclude" [*2*], I do not mind too much if the UI expressed negative pathspecs using such a new command line option, but I think it would be more natural to say (notations aside):

	$ git log -- ':(no):po' .

and define the behaviour of user-supplied pathspec limiter this way:

 * Paths are matched from left to right;

 * First match determines the fate of the path;

 * A match with negative pathspec means "the path in question does _not_
   match".

[Footnote]

*1* Unlike the "This is _one_ possible way" I usually give in discussions, this is "The narrow clone _must_ work like this, if we were to add it".

*2* I would suggest not using --exclude to avoid giving users a wrong impression that this might have something to do with exclude patterns. How about calling it "--filter-out" instead?