On Sat, Mar 19, 2016 at 1:00 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > What is the ultimate goal of nd/exclusion-regression-fix topic over > the behaviour before 2.7.0 and after 2.7.1 (there was a regression > in 2.7.0 that was reverted in 2.7.1)? From the cover letter of the > series: > > Take one was bad and reverted in commit 8c72236. Take two provides a > more complete solution to the pair of rules > > exclude/this > !exclude/this/except/this > > 3/4 should do a better job at stopping regressions in take 1. 4/4 > provides the solution. I think I have tested (and wrote tests) for all > the cases I can imagine. > > "solution to the pair of rules" hints there are some problem in the > pair of rules, without stating what it is trying to solve. > > Isn't the root cause of the issue that treat_one_path() when > deciding if it is worth descending into a directory check if the > directory itself is excluded and returns path_excluded, even if some > paths inside it may have a countermanding ! entries that would match > them? What if we change that part smarter and allow it to descend? That's the easy part, detecting a pair and continue descending. The problem is after you descend, exclude engine may return contradicting results on old patterns. It's the same thing that 3/2 describes (after you change patterns from "!dir\ndir/file2" to "dir\n!dir/file2"). -- 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