The fix on my side was quite easy (and my .gitignore is probably a _lot_ hairier than most), and as Duy suggests, I think the new behavior makes a bit more sense. Personally, I would be pleased with keeping the new behavior, and chalking it up to an unintentional bug fix (the best kind). Either way, of course, I'd like for it to not change back and forth between releases :). Perhaps just an announcement of the new behavior would suffice - 2.7.0 has been out for a while anyway. If people were going to complain, I figure they would have done so by now. -Charles On Fri, Mar 4, 2016, at 07:50 PM, Duy Nguyen wrote: > typo fixes > > On Sat, Mar 5, 2016 at 7:43 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > On Sat, Mar 5, 2016 at 12:28 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> Duy Nguyen <pclouds@xxxxxxxxx> writes: > >> > >>> On Fri, Mar 4, 2016 at 6:56 PM, Kevin Daudt <me@xxxxxxxxx> wrote: > >>>> Verified that it's different in 2.7.0, but 2.7.2 gives expected output. > >>> > >>> Thanks. 2.7.1 reverts the faulty commit from 2.7.0 that generated two > >>> other regression reports before this one. I guess it's all good then > >>> (except for the people still on 2.7.0) > >> > >> Are we good at 2.8.0-rc0, too? Somehow I had an impression that we > >> queued "another attempt to do it differently" or something. > >> > >> ... goes and looks ... > >> > >> $ rungit maint status -suall > >> ?? baz/quux/corge/wibble.txt > >> ?? baz/quux/grault.txt > >> ?? foo/bar.txt > >> $ rungit master status -suall > >> ?? baz/quux/corge/wibble.txt > >> ?? baz/quux/grault.txt > >> ?? baz/waldo.txt > >> ?? foo/bar.txt > >> ?? foo/garply.txt > > > > If you swap a60ea8f and bac65a2 so that we can have tracing even > > without the problematic commit a60ea8f (dir.c: fix match_pathname() - > > 2016-02-15). Without a60ea8f I got > > > > GIT_TRACE_EXCLUDE=1 ~/w/git/temp/git status -suall 2>&1 >/dev/null > > |grep waldo > > 07:25:05.639445 dir.c:952 exclude: baz/waldo.txt vs * at > > line 1 => yes > > > > (meaning, baz/waldo.txt matches "*" rule and is decided to be excluded) > > > > with a60ea8f > > > >> /tmp/abc $ GIT_TRACE_EXCLUDE=1 ~/w/git/temp/git status -suall 2>&1 >/dev/null |grep waldo > > 07:25:24.425125 dir.c:952 exclude: baz/waldo.txt vs /baz > > at line 4 => no > > > > the decision is not taken earlier from line "!/baz" and it's decided > > s/not taken/taken/ > > > to be re-included. Which I would argue is the correct thing because > > you ask to re-include the whole directory "baz". It should behave this > > way because exclude rules without '!' behave this way. > > > > Because positive any negative rules can be nested, by adding a rule to > > s/any/and/ > > > reinclude what's inside baz.. > > > > * > > !/foo > > !/foo/bar.txt > > !/baz > > /baz/* > > !/baz/quux > > !/baz/quux/**/* > > > > you'll get baz/waldo.txt excluded. > > > > Yes it's a behavior change. I think the old behavior is unintended. > > But it's probably out there long enough that many .gitignore files may > > rely on it and by making it right, I break them. Whether to revert the > > series is up to you. Let me know if I should send the revert patch. > > -- > > Duy > > > > -- > 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