Chris Torek [off-list ref] writes:
... So the standard
explanation -- at least, the one I use -- is this:
* Git opens and reads the working tree directory. For each file
or directory that is actually present here, Git checks it
against the ignore rules. Some rules match only directories
and others match both directories and files. Some rules say
"do ignore" and some say "do not ignore".
* The *last* applicable rule wins.
* If this is a file and the file is ignored, it's ignored.
Unless, that is, it's in the index already, because then it's
tracked and can't be ignored.
* If this is a directory and the directory is ignored, it's
not even opened and read. It's not in the index because
directories are never in the index (at least nominally).
If it is opened and read, the entire set of rules here
apply recursively.
This works, but skips over files that are in the index and are in
a directory that won't be read. So I add one last rule, which is
All of the above is sensible. If you deal with a path that is in
the index upfront, you can simplify the later rules somewhat, I
would think. I.e. add a first rule before everything else that
says:
* A file in the index is not ignored. Everything below is about a
path not in the index.
Then your third rule can lose "Unless...", and you do not have to
add one last rule outside the bulleted list, either.
;-)
On 21/11/2021 00:46, Junio C Hamano wrote:
Chris Torek [off-list ref] writes:
quoted
... So the standard
explanation -- at least, the one I use -- is this:
* Git opens and reads the working tree directory. For each file
or directory that is actually present here, Git checks it
against the ignore rules. Some rules match only directories
and others match both directories and files. Some rules say
"do ignore" and some say "do not ignore".
* The *last* applicable rule wins.
* If this is a file and the file is ignored, it's ignored.
Unless, that is, it's in the index already, because then it's
tracked and can't be ignored.
* If this is a directory and the directory is ignored, it's
not even opened and read. It's not in the index because
directories are never in the index (at least nominally).
If it is opened and read, the entire set of rules here
apply recursively.
This works, but skips over files that are in the index and are in
a directory that won't be read. So I add one last rule, which is
All of the above is sensible. If you deal with a path that is in
the index upfront, you can simplify the later rules somewhat, I
would think. I.e. add a first rule before everything else that
says:
* A file in the index is not ignored. Everything below is about a
path not in the index.
Then your third rule can lose "Unless...", and you do not have to
add one last rule outside the bulleted list, either.
;-)
Perhaps, the clarifications are an opportunity to improve the
documentation, should the Danial think that the explanation would have
helped. The 'ignore' matching rules does appear to show up quite often
on the list.
Any thoughts, Danial?
Philip
* Git opens and reads the working tree directory. For each file
or directory that is actually present here, Git checks it
against the ignore rules. Some rules match only directories
and others match both directories and files. Some rules say
"do ignore" and some say "do not ignore".
* The *last* applicable rule wins.
* If this is a file and the file is ignored, it's ignored.
Unless, that is, it's in the index already, because then it's
tracked and can't be ignored.
* If this is a directory and the directory is ignored, it's
not even opened and read. It's not in the index because
directories are never in the index (at least nominally).
If it is opened and read, the entire set of rules here
apply recursively.
I do think it would be sensible for Git to read a `.gitignore`
that says:
*
!a/b/c
as meaning:
*
!a/
!a/b/
!a/b/c
That is, declaring an un-ignored file within some ignored
directory should automatically imply that we *must* un-ignore the
parents.
Thanks, Chris. Yes, it mostly makes sense to me too.
I think this will better describe the gitignore behavior.
However, checking the indexed files at first may enhance it.
In addition to that, there should be an exception about negating patterns.
For example, for the "!**/file.txt" pattern, it might be tricky to
re-include all possible parents of "file.txt" files. You have to
traverse directories to reach files and find out which parents to
un-ignore. Any negating pattern with "**" at the beginning or in the
middle of the pattern can make trouble.
The existing rule which states the file cannot be re-included in case
of ignored parents may help to prevent this.
Thanks
Danial