Re: Expanding Includes in .gitignore

On Thu, Oct 27, 2016 at 04:55:08PM -0400, Jeff King wrote:

On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:

quoted

quoted

  - we parse possibly-hostile .gitignore files from cloned repositories.
    What happens when I include ask to include /etc/passwd? Probably
    nothing, but there are setups where it might matter (e.g., something
    like Travis that auto-builds untrusted repositories, and you could
    potentially leak the contents of files via error messages). It's
    nice to avoid the issue entirely.

I understand the issue.

It's not obvious to me how using a .d solves this problem though.

It doesn't by itself. But we are worried only about tracked .gitignore
files (recall that even repo-level files in $GIT_DIR/info are generated
fresh by the clone process, and don't come from the remote). If we apply
the feature only to core.excludeFile and $GIT_DIR/info/exclude, those
are already under the user's control.

It's true that we could make a similar exception for an "include"
feature, and respect include directives only in those "safe" files.
Somehow that seems more confusing to me, though, than doing adding the
feature at the file level, as it introduces slightly varying syntax
between the locations.

Actually, I suppose even a ".gitignore.d" inside the repo solves that
problem, too, because the repository is not specifying paths, only
content (it can specify symlinks outside the repository, but like other
parts of git, we should be careful not to follow them in that case).

However, as I said elsewhere, I'm not convinced this feature is all that
helpful for in-repository .gitignore files, and I think it does
introduce compatibility complications. People with older git will not
respect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local
matter.

But perhaps there is a use case I'm missing.

-Peff