From: Junio C Hamano <gitster@pobox.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Durham Goode <durham@fb.com>,
Git Mailing List <git@vger.kernel.org>,
Mateusz Jakub Kwapich <mitrandir@fb.com>
Subject: Re: [PATCH 3/2] dir.c: fix dir re-inclusion rules with "NODIR" and "MUSTBEDIR"
Date: Fri, 18 Mar 2016 11:00:06 -0700 [thread overview]
Message-ID: <xmqqa8lvr7ix.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CACsJy8A2FKn-8nWtK4QPMHDCDYvTZBrQs1RVMApnuejXQis19g@mail.gmail.com> (Duy Nguyen's message of "Fri, 18 Mar 2016 12:40:09 +0700")
Duy Nguyen <pclouds@gmail.com> writes:
> v2.7.3 differs in the way "!" is handled. It does extend reversion
> outside dir1/dir2/show, back to dir1/dir2. While 2.8+1+2 recognizes
> and follows the "/*" and "!dir1/dir2/" pair.
>
> The way I interpreted the rules above, though, may be because I'm just
> trying to defend the current code. Junio, your call on whether to
> revert this whole patch series.
It seems that the more you dig into piling changes on this topic
there is somebody else who comes back with yet another corner case.
At this point in the release cycle, I am inclined to say that we
should revert the whole thing from 2.8-rc. Even with that plan, we
probably need an extra rc as the reverting a topic this late in the
cycle is something I feel uncomfortable with.
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?
next prev parent reply other threads:[~2016-03-18 18:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-17 0:09 bug: sparse config interpretation incorrectness in 2.8.0-rc2 Durham Goode
2016-03-17 0:56 ` Duy Nguyen
2016-03-17 6:49 ` Durham Goode
2016-03-17 7:51 ` Junio C Hamano
2016-03-17 10:17 ` Duy Nguyen
2016-03-17 13:04 ` Johannes Schindelin
2016-03-17 13:20 ` Duy Nguyen
2016-03-17 13:46 ` Johannes Schindelin
2016-03-17 14:00 ` Duy Nguyen
2016-03-18 15:49 ` Johannes Schindelin
2016-03-17 7:22 ` Junio C Hamano
2016-03-17 17:51 ` Durham Goode
2016-03-17 12:45 ` [PATCH 1/2] dir.c: fix bug in 'nd/exclusion-regression-fix' topic Nguyễn Thái Ngọc Duy
2016-03-17 12:45 ` Nguyễn Thái Ngọc Duy
2016-03-17 12:54 ` [PATCH 3/2] dir.c: fix dir re-inclusion rules with "NODIR" and "MUSTBEDIR" Nguyễn Thái Ngọc Duy
2016-03-17 23:49 ` Junio C Hamano
2016-03-18 0:15 ` Duy Nguyen
2016-03-18 5:40 ` Junio C Hamano
2016-03-18 5:51 ` Duy Nguyen
2016-03-18 5:58 ` Eric Sunshine
2016-03-18 4:51 ` Durham Goode
2016-03-18 5:40 ` Duy Nguyen
2016-03-18 6:21 ` Durham Goode
2016-03-18 6:28 ` Duy Nguyen
2016-03-18 18:00 ` Junio C Hamano [this message]
2016-03-18 18:37 ` Extending this cycle by a week and reverting !reinclusion topic Junio C Hamano
2016-03-19 1:03 ` [PATCH 3/2] dir.c: fix dir re-inclusion rules with "NODIR" and "MUSTBEDIR" Duy Nguyen
2016-03-17 12:45 ` [PATCH 2/2] dir.c: correct "stuck" logging logic Nguyễn Thái Ngọc Duy
2016-03-17 12:45 ` Nguyễn Thái Ngọc Duy
2016-03-18 17:38 ` [PATCH 1/2] dir.c: fix bug in 'nd/exclusion-regression-fix' topic Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa8lvr7ix.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=durham@fb.com \
--cc=git@vger.kernel.org \
--cc=mitrandir@fb.com \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.