gitignore: how to exclude a directory tree from being ignored

> Hi
> I want to exclude binaries except in a dir tree that I do not control.
> 
> In .gitignore  I have:
> 
> 
> I would expect that all *.exe and *.o are ignored except those somewhere
> in the vendor dir tree.
> However, the *.exe and *.o in the vendor dir tree are also ignored.

> Peter schrieb:
>   
>> Hi
>> I want to exclude binaries except in a dir tree that I do not control.
>>
>> In .gitignore  I have:
>>
>>
>> I would expect that all *.exe and *.o are ignored except those somewhere
>> in the vendor dir tree.
>> However, the *.exe and *.o in the vendor dir tree are also ignored.
>>     
>
> This works for me:
>
>  *.exe
>  *.o
>  !vendor/*.exe
>  !vendor/*.o
>
> Note that git-status does not descend into directories from which no files
> are tracked. Therefore, this will work only after you have git-added at
> least one file from vendor/.
>
> git ls-files -o --exclude-standard does descend into the directory.
>
> Furthermore, the !vendor/*.exe patterns are not recursive. Perhaps it is
> easier for you to have a separate vendor/.gitignore that has:
>
>  !*.exe
>  !*.o
>
> These _are_ recursive.
>
> -- Hannes
>   

> Johannes Sixt wrote:
>> Peter schrieb:
>>  
>>> Hi
>>> I want to exclude binaries except in a dir tree that I do not control.
>>>
>>> In .gitignore  I have:
>>>
>>>
>>> I would expect that all *.exe and *.o are ignored except those somewhere
>>> in the vendor dir tree.
>>> However, the *.exe and *.o in the vendor dir tree are also ignored.
>>>     
>>
>> This works for me:
>>
>>  *.exe
>>  *.o
>>  !vendor/*.exe
>>  !vendor/*.o
>>
>> Note that git-status does not descend into directories from which no
>> files
>> are tracked. Therefore, this will work only after you have git-added at
>> least one file from vendor/.
>>
>> git ls-files -o --exclude-standard does descend into the directory.
>>
>> Furthermore, the !vendor/*.exe patterns are not recursive. Perhaps it is
>> easier for you to have a separate vendor/.gitignore that has:
>>
>>  !*.exe
>>  !*.o
>>
>> These _are_ recursive.
> 
> 1) I can't have just one .gitignore file in the root dir, if I want to
> _recursively_ inverse the exclude pattern for a sub dir tree.

> 2) In order to see what will be staged, I have to use the :
> git ls-files -o --exclude-standard
> instead of :
> git ls-files -o -i --exclude-from=.gitignore
> because the latter won't consider .gitignore patterns in subtree

>> 1) I can't have just one .gitignore file in the root dir, if I want to
>> _recursively_ inverse the exclude pattern for a sub dir tree.
>>     
>
> No, it's not the inversion of the pattern, but the slash (if it is not at
> the end) that makes the pattern non-recursive.
>
>   

>> In this case, I have to put individual .gitignore files in the sub trees
>> I want to re-include.
>>     
>
> If you have only the directory vendor/ with no further interesting
> subdirectories, then you can use my first suggestion. But if you have your
> *.exe and *.o distributed over several directories of different depths
> below vendor/, then it might be easier to have a separate
> vendor/.gitignore with recursive patterns (i.e. that do not contain a slash).
>
>   

>> 2) In order to see what will be staged, I have to use the :
>> git ls-files -o --exclude-standard
>> instead of :
>> git ls-files -o -i --exclude-from=.gitignore
>> because the latter won't consider .gitignore patterns in subtree
>>     
>
> After reading the documentation, I don't know, and I won't try now ;-)
>
>   

>>> 1) I can't have just one .gitignore file in the root dir, if I want to
>>> _recursively_ inverse the exclude pattern for a sub dir tree.
>>>     
>>
>> No, it's not the inversion of the pattern, but the slash (if it is not at
>> the end) that makes the pattern non-recursive.
>>
>>   
> from the gitignore manpage:
>>> If the pattern ends with a slash, it is removed for the purpose of
> the following description, but it would only find a match with a
> directory. In other words, foo/ will match a directory foo and paths
> underneath it, but will not match a regular file or a symbolic link foo
> (this is consistent with the way how pathspec works in general in git). <<
> 
> Doesn't this mean, that if I say:
> vendor/
> matches the directory and ( recursively ) the paths underneath it.?

> And, consequently:
> !vendor/
> inverse the exclusion for vendor ( that is: include ) and everything
> that is contained in it ? ( This is obviously not the case, but this is
> what I would expect )

> Peter schrieb:
>   
>>>> 1) I can't have just one .gitignore file in the root dir, if I want to
>>>> _recursively_ inverse the exclude pattern for a sub dir tree.
>>>>     
>>>>         
>>> No, it's not the inversion of the pattern, but the slash (if it is not at
>>> the end) that makes the pattern non-recursive.
>>>
>>>   
>>>       
>> from the gitignore manpage:
>>     
>>>> If the pattern ends with a slash, it is removed for the purpose of
>>>>         
>> the following description, but it would only find a match with a
>> directory. In other words, foo/ will match a directory foo and paths
>> underneath it, but will not match a regular file or a symbolic link foo
>> (this is consistent with the way how pathspec works in general in git). <<
>>
>> Doesn't this mean, that if I say:
>> vendor/
>> matches the directory and ( recursively ) the paths underneath it.?
>>     
>
> The paragraph you are citing is talking about *what* the pattern matches,
> but it says nothing about *where* the pattern matches.
>
> When I was saying "recursively", then I was refering to the "where"
> aspect, not the "what" aspect.
>
> If you have directories
>
>    src/bar/vendor/
>    src/foo/bar/vendor/
>    src/vendor/
>
> and you have the file src/.gitignore with the single pattern
>
>    vendor/
>
> then it applies to recursively ("where") these directories:
>
>    src/bar/vendor/
>    src/foo/bar/vendor/
>    src/vendor/
>
> and everything ("what") below them.
>
> But if the same src/.gitignore has only this pattern:
>
>    bar/vendor/
>
> then it will not match ("where") recursively and only apply to
>
>    src/bar/vendor/
>
> and everything ("what") below it, but will not apply to
>
>    src/foo/bar/vendor/
>
>   
>> And, consequently:
>> !vendor/
>> inverse the exclusion for vendor ( that is: include ) and everything
>> that is contained in it ? ( This is obviously not the case, but this is
>> what I would expect )
>>     
>
> You should update your expectations. ;-)
>
> You think that git starts with the .gitignore files, and somehow applies
> the rules that it finds to all files (perhaps recursively).
>
> But it does not work like this; rather it is in the oppsite direction: git
> starts with a file name, and then checks the rules in the .gitignore files
> that it has available.
>
> For example, take the path "src/vendor/foo.exe". git finds the file
> src/.gitignore and there it sees the pattern "*.exe". The pattern matches,
> and so git obeys the rule (ignores the file). But the pattern "!vendor/"
> does not match (because the path ends with "foo.exe", not "vendor").
>
> Before git had seen the path "src/vendor/foo.exe", it had already seen
> "src/vendor". This time the pattern "!vendor/" did match (because the name
> is identical *and* it is a directory, as per the cited paragraph) and git
> obeyed the rule (which was not to ignore the directory).
>
> -- Hannes
>