On Sun, Mar 22, 2015 at 10:33 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > On Fri, Mar 20, 2015 at 6:36 AM, <mdconf@xxxxxxxxx> wrote: >> I am trying to setup my git ignore (resp. .git/info/exclude) so that I exclude >> all directories and files except the content of directories that I >> specifically include (incl. anything within them recursively). >> >> I set the .git/info/exclude with the following content: >> >> ======== >> # Exclude everything >> /* >> # Except the below that we include >> !/db/data/load/base/bootstraponly >> !/db/data/load/base/safetoload >> !/db/ddl >> !/labels >> !/reports/usrint >> !/scripts >> !/src/cmdsrc/usrint >> ======== >> >> However it does not do what I anticipated. It indeed excludes everything but >> the include part does not work - it only works for !/labels and !/scripts >> directories (i.e. the first level directories). All other are still ignored - >> so when I create file /db/data/load/base/bootstraponly/somefile.txt git still >> ignores it... >> >> Any idea what I am doing wrong? > > The fourth bullet point of the "Pattern Format" section of the > gitignore man page has this to say, which explains the behavior you're > seeing: > > An optional prefix "!" which negates the pattern; any matching > file excluded by a previous pattern will become included again. > It is not possible to re-include a file if a parent directory of > that file is excluded. Git doesn’t list excluded directories for > performance reasons, so any patterns on contained files have no > effect, no matter where they are defined. This is true. To elaborate, if we have to recurse in excluded directories so that we can include some back, then the reason for excluding is already defeated as we may need to traverse the entire directory structure. However in this particular case where we do know in advance that only certain directories may have "re-include" rules, e.g. "db", "reports" or "scripts", we could keep going for a while. I think I attempted to do this in the past and failed (don't remember exactly why). Maybe I'll try again some time in future. Another option is, if the user is willing to accept performance degradation (in many small repos, it does not matter anyway), then we could keep digging in. -- 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