On 27/10/16 21:19, Alexei Lozovsky wrote: >> I'm thinking something like ". path/to/include/file" in an ignore file, >> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore >> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent >> mixture of these things. > > I think the rc.d-like approach with directories is better as it > does not add new magical filenames (what if I absolutely do need > to name my directories ". path", with a space? :) Yes. Another alternative I thought of was #include path/to/include/file. That'd be backwards compatible, which is a good thing, but would involve parsing comments, which obviously could start with #include. Or lines like ^Include /path/file$ In the case of finding an invalid file, passing it over and issuing a simple warning should surface any issues with existing gitignores. Anyway, this conversation is why I bring it up on the list. Coming back to this, maybe :(include)/path/file might be more git-like >> In the case of a directory the plan would be to add links to files >> stored/sourced elsewhere. This does pose a precedence question which I >> haven't thought about yet, but probably makes it too hard for the >> limited value it brings. > > Now, if we consider the case of multiple .gitignore files, it > could be unexpected and possibly annoying for negative patterns > in one file to affect the patterns added by some other files. That is a concern. It is non obvious; the worst kind of annoying. > I would find it more conceptually simple to apply individual > .gitignores one by one, as opposed to parsing them all and > creating one giant exclusion rule. (In technical terms, this > means keeping one struct exclude_list for each .gitignore, > not merging them all into one single list.) I agree. I haven't looked, but that sounds like touching significantly more code though. Actually, thinking about it for 20 seconds more, it shouldn't be too hard, should it? > In this case there should be no precendence problems as applied > gitignores only add new ignored files, without un-ignoring > anything previously ignored by other files. Again, I haven't looked yet, but there is still an issue of precedence with other gitignore files in $HOME and the repo. > However, if we allow textual inclusion, then it means that we > can put a gitignore into our gitignore so that we can unignore > while we ignore, which again brings us the question of whether > it is actually needed and expected. Gah! Yes. One way or the other. >> I would like to know the desirability/practicality/stupidity of such a >> feature as I believe it is within my skillset to implement it. > > However, I do not recall any precendent of git using rc.d-like > configs. Many things have adopted this technique recently. Well, the last 15 years. It is common, understood, and fairly simple. I see no issue with it. > And some can argue that your goal can be achieved by > generating the .gitignore by some external means and symlinking > the result into .git/info/exclude, so this is not Git's problem > and we should not be overcomplicating things with something as > simple as a list exclude patterns. This line of argument also > can be used to opposes any textual inclusion as well, because > it can be expanded into 'why don't we add a Turing-complete > programming language then to specify the patterns to ignore'. I know. Another reason to bring the idea to the list. I sort of have this attitude myself. My main objection to it is that I can't think of a hook to automate it with. But: What about some kind of :(exec) that executes a script and returns a gitignore file? You write the script; you're responsible. And the behaviour is obvious. I haven't thought that through. It just came to me then, and might present security issues, but could greatly simplify things.