Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > This series adds --exclude that uses .gitignore mechanism remove > commits whose changes that are _entirely_ excluded. 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html