The current documentation reads as if .gitignore files will be parsed in
every parent directory, and not until they reach a repository boundary.
This clarifies the current behaviour.
Signed-off-by: Andrew Berry <redacted>
---
Documentation/gitignore.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 53e7d5c914..534cda5747 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -27,10 +27,10 @@ precedence, the last matching pattern decides the outcome):
them.
* Patterns read from a `.gitignore` file in the same directory
- as the path, or in any parent directory, with patterns in the
- higher level files (up to the toplevel of the work tree) being overridden
- by those in lower level files down to the directory containing the file.
- These patterns match relative to the location of the
+ as the path, or in any parent directory in the same repository, with
+ patterns in the higher level files (up to the toplevel of the work tree)
+ being overridden by those in lower level files down to the directory
+ containing the file. These patterns match relative to the location of the
`.gitignore` file. A project normally includes such
`.gitignore` files in its repository, containing patterns for
files generated as part of the project build.--
2.31.1
On 03/07/21 05.20, Andrew Berry wrote:
* Patterns read from a `.gitignore` file in the same directory
- as the path, or in any parent directory, with patterns in the
- higher level files (up to the toplevel of the work tree) being overridden
- by those in lower level files down to the directory containing the file.
- These patterns match relative to the location of the
+ as the path, or in any parent directory in the same repository, with
+ patterns in the higher level files (up to the toplevel of the work tree)
+ being overridden by those in lower level files down to the directory
+ containing the file. These patterns match relative to the location of the
So for example I have `something/foo` in ../.gitignore, but .gitignore
(in current directory `something`) has `foo`. Is .gitignore from current
directory or ../.gitignore takes effect?
Also s/toplevel/top level/
--
An old man doll... just what I always wanted! - Clara
On 2 Jul 2021, at 20:06, Junio C Hamano wrote:
I would have thought that "up to the toplevel of the work
tree" would be sufficiently clear where the upward traversal of the
directories ends, i.e. at the repository boundary.
Seems reasonable. What if we move that note to come after "any parent
directory"?
On 2 Jul 2021, at 20:21, Bagas Sanjaya wrote:
So for example I have `something/foo` in ../.gitignore, but .gitignore
(in current directory `something`) has `foo`. Is .gitignore from
current directory or ../.gitignore takes effect?
In this case, both rules resolve to the same path, so I don't think it
matters? But in practice I'd expect it to be `something/.gitignore`,
since you can negate the pattern from the parent ignore file.
Also s/toplevel/top level/
That showed up in the diff due to word wrapping. If no other changes are
accepted, I'll file a followup after to get this fixed on it's own.