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 )
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).
This works for me ( I have indeed distributed them over several dirs )
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 ;-)
At least it seams to work here ..
-- Hannes
Thanks !
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html