Re: [PATCH] docs: .gitignore parsing is to the top of the repo

2 messages, 2 authors, 2021-07-07 · open the first message on its own page

Re: [PATCH] docs: .gitignore parsing is to the top of the repo

From: Junio C Hamano <hidden>
Date: 2021-07-07 00:18:50

Junio C Hamano [off-list ref] writes:
Andrew Berry [off-list ref] writes:
quoted
  * 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
-   `.gitignore` file.  A project normally includes such
-   `.gitignore` files in its repository, containing patterns for
+   as the path, or in any parent directory (up to the top-level of the work
+   tree), with patterns in the higher level files 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.
Line rewrapping makes it hard to see what actually got changed, but
does this only move "(up to the top-level of the work tree)" around
without anything else, as discussed?

If you do "toplevel" -> "top-level" while at it, perhaps we would
want to correct "work tree" -> "working tree".

Looking better.
Another tangent.  The discovery process used for the .gitattributes
files is identical to what is done to the .gitignore files; we may
want to make sure that the explanation we give in our documentation
won't cause the same confusion you are trying to avoid with this
change.  Such a fix does not have to be (and probably should not be)
a part of this change, though.

Thanks.

Re: [PATCH] docs: .gitignore parsing is to the top of the repo

From: Andrew Berry <hidden>
Date: 2021-07-07 00:32:55

On 6 Jul 2021, at 20:18, Junio C Hamano wrote:
Junio C Hamano [off-list ref] writes:
quoted
Line rewrapping makes it hard to see what actually got changed,
To check, that's asked for, correct? Or is it better to do one commit 
with the word changes, another to clean up the wrapping?
quoted
but
does this only move "(up to the top-level of the work tree)" around
without anything else, as discussed?

If you do "toplevel" -> "top-level" while at it, perhaps we would
want to correct "work tree" -> "working tree".

Looking better.
Yes, I realized I sent the wrong file when reviewing the sent email, 
hence the followup. Aside, it's not clear to me how to send patch emails 
that _also_ have not-to-be-committed notes like "oops, ignore the last". 
First time contributor problems!
Another tangent.  The discovery process used for the .gitattributes
files is identical to what is done to the .gitignore files; we may
want to make sure that the explanation we give in our documentation
won't cause the same confusion you are trying to avoid with this
change.  Such a fix does not have to be (and probably should not be)
a part of this change, though.
I'm out of the office for the next week, but otherwise I'm glad to take 
that on when I'm back if no one else picks it up.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help