* When --exclude-per-directory=<name> is specified, upon
entering a directory that has such a file, its contents are
appended at the end of the current "list of patterns". They
are popped off when leaving the directory.
[...]
A pattern specified on the command line with --exclude or read
from the file specified with --exclude-from is relative to the
top of the directory tree. A pattern read from a file specified
by --exclude-per-directory is relative to the directory that the
pattern file appears in.
I think it would make more sense for the exclude-per-directory
patterns to be local to that directory only, without recursively
preserving them for subdirectories. One would, in general, put the
common exclude patterns like *.o *~ etc. in the global file
(.git/exclude). The patterns local to a directory only (take the
vmlinux file for example), one would write it in the .gitignore file
but this should be used for subdirectories.
An exclude pattern is of the following format:
[...]
That's fine. Actually, the Porcelain would care much about it since it
gets the information already filtered by git.
$ cat Documentation/.gitignore
# ignore generated html files,
# except foo.html which is maintained by hand
!foo.html
*.html
Wouldn't it be clearer to have the general rules first (*.html),
overridden by the more specific ones (!foo.html)? Just my opinion, I
don't know what others think.
--
Catalin
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:02
Catalin Marinas [off-list ref] writes:
I think it would make more sense for the exclude-per-directory
patterns to be local to that directory only, without recursively
preserving them for subdirectories.
I personally do not have preference either way, but am slightly
biased towards the "cumulative" behaviour the patch attempts to
implement, which was what Pasky said he wanted to have.
Date: Fri, 22 Jul 2005 22:59:48 +0200
From: Petr Baudis [off-list ref]
Subject: Re: [PATCH 1/1] Tell vim the textwidth is 75.
Message-ID: [off-list ref]
> *3* .gitignore in the cwd is used in Cogito, if I am not
> mistaken.
Yes. There were several discussions about this in the past, with no
clear outcome, IIRC. I would prefer:
~/.git/ignore per-user
/.git/ignore per-repository
.gitignore per-directory (cummulative with parent directories)
quoted
An exclude pattern is of the following format:
[...]
That's fine. Actually, the Porcelain would care much about it since it
gets the information already filtered by git.
Your saying "fine" is a relief. This change aims at helping
Porcelain people by making it less likely for Porcelain to need
its own filtering. As you say, if ls-files filters more than
the Porcelain wants, that's a bigger problem.
quoted
$ cat Documentation/.gitignore
# ignore generated html files,
# except foo.html which is maintained by hand
!foo.html
*.html
Wouldn't it be clearer to have the general rules first (*.html),
overridden by the more specific ones (!foo.html)? Just my opinion, I
don't know what others think.
I do not know, either, but I do know it is consistent with the
"first match determines fate" rule and cleaner to implement.
I personally do not have preference either way, but am slightly
biased towards the "cumulative" behaviour the patch attempts to
implement, which was what Pasky said he wanted to have.
I think that makes sense.
Imagine, for example, that you have separate subdirectory structures for
Documentation and for source - maybe you'd put the "*.o" rule in the
source directory, and a "*.1" rule in the Docs subdirectory.
Linus
On Mon, 2005-07-25 at 12:58 -0700, Junio C Hamano wrote:
Catalin Marinas [off-list ref] writes:
quoted
quoted
An exclude pattern is of the following format:
[...]
That's fine. Actually, the Porcelain would care much about it since it
gets the information already filtered by git.
Your saying "fine" is a relief. This change aims at helping
Porcelain people by making it less likely for Porcelain to need
its own filtering. As you say, if ls-files filters more than
the Porcelain wants, that's a bigger problem.
I don't plan to add any additional filtering in StGIT. What I meant
above was that Porcelain would not care much about the patterns. The
user should cope with what git provides, nothing more. With these git
patches, I think there are enough features for filtering.
quoted
Wouldn't it be clearer to have the general rules first (*.html),
overridden by the more specific ones (!foo.html)? Just my opinion, I
don't know what others think.
I do not know, either, but I do know it is consistent with the
"first match determines fate" rule and cleaner to implement.
I also don't have a strong preference for this and the "first match"
rule clarifies it (otherwise, you could have pushed them on a list in
reverse order).
--
Catalin