On Thu, Mar 24, 2016 at 11:50 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >>> On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>> 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. >> >> I went with a new option instead of changing --include. > > It might be a "workable" band-aid, but would be an unsatisfying UI > if it were the endgame state. You do not say "git grep --whole" (by > the way, "whole" is a bad option name, as you cannot tell "100% of > *what*" you are referring to--what you are widening is the limit > based on the location in the directory structure, so the option name > should have some hint about it, e.g. "full-tree" or something) and > this command will become an odd-man-out. > > I haven't thought things through, but thinking out aloud a few > points... > > An existing user/script may be working in a subdirectory of a huge > working tree and relies on the current behaviour that outside world > is excluded by default, and may be passing --exclude to further > limit the extent of damage by applying the patch to a subset of > paths in the current directory that itself is also huge. And that > use case would not be harmed by such a change. > > On the other hand, an existing user/script would not be passing an > "--include" that names outside the current subdirectory to force > them to be included, because it is known for the past 10 years not > to have any effect at all. Real-world .gitignore patterns have taught me that even if it does not have any effect, it might still be present in some scripts, waiting for a chance to bite me. > So a better alternative may be to conditionally disable the "Paths > outside are not touched regardless of --include" logic, i.e. we > exclude paths outside by default just as before, but if there is at > least one explicit "--include" given, we skip this "return 0". > > That way, we do not have to commit to turning --include/--exclude to > pathspec (which I agree is a huge change in behaviour that may not > be a good idea) and we do not have to add "--full-tree" that is only > understood by "apply" but not other commands that operate on the > current directory by default. But your suggestion is good and I can't think of any better. We could introduce pathspec as ftiler after "--", but it does not look elegant, and it overlaps with --include/--exclude. Perhaps we can start to warn people if --include is specified but has no effect for a cycle or two, then we can do as you suggested? -- Duy -- 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