Duy Nguyen <pclo...@gmail.com> writes: >> The include/exclude mechanism does use wildmatch() but does not use >> the pathspec mechanism (it predates the pathspec machinery that was >> made reusable in places like this). We should be able to >> >> $ cd d/e/e/p/d/i/r >> $ git apply --include=:/ ../../../../../../../patch >> >> to lift this limitation. IOW, we can think of the use_patch() to >> include only the paths in the subdirectory we are in by default, but >> we can make it allow --include/--exclude command line option to >> override that default. > > Interesting. Disabling that comment block seems to work ok. So > git-apply works more like git-grep, automatically narrowing to current > subdir, rather than full-tree like git-status.
We used to have one argument when choosing between "limit to cwd" vs "work on full-tree" defaults, i.e. "a full-tree thing can easily be limited to cwd by passing '.' as a pathspec, but limited-to-cwd thing cannot be widened" before we introduced the magic "full-tree" pathspec. This "limit to cwd" behaviour of "git apply" predates that by several years. > git-apply.txt should > probably mention about this because (at least to me) it sounds more > naturally that if I give a patch, git-apply should apply the whole > patch. Yes, documentation update is necessary. > We probably should show a warning if everything file is filtered out > too because silence usually means "good" from a typical unix command. We should give an informational message if _anything_ is filtered out, I would say. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
