On Tue, Aug 21, 2012 at 09:50:27AM -0700, Junio C Hamano wrote:
Show 18 quoted lines
> > Subject: [PATCH] gitignore: report access errors of exclude files
> >
> > When we try to access gitignore files, we check for their
> > existence with a call to "access". We silently ignore
> > missing files. However, if a file is not readable, this may
> > be a configuration error; let's warn the user.
> >
> > For $GIT_DIR/info/excludes or core.excludesfile, we can just
> > use access_or_warn. However, for per-directory files we
> > actually try to open them, so we must add a custom warning.
>
> There are a couple of users of add_excludes_from_file() that is
> outside the per-directory walking in ls-files and unpack-trees; I
> think both are OK with this change, but the one in ls-files may want
> to issue a warning or even an error upon ENOENT.
>
> Not a regression with this patch; just something we may want to do
> while we are in the vicinity.
The two I see are:
1. unpack-trees:verify_absent
This looks like it is reading info/sparse-checkout. But I think it
is OK for that file to be missing, no? 2. ls-files:option_parse_exclude_from
This handles --exclude-from. I would expect most callers to be
converted to --exclude-standard these days, but originally callers
did something like: git ls-files \
--exclude-from=$GIT_DIR/info/exclude \
--exclude-per-directory=.gitignore \
... While it would be friendlier to a user calling ls-files to warn
about a missing entry in the first case (since they explicitly
typed it, they presumably expect it to work). But for a script
calling the ls-files plumbing, that --exclude-from has always
meant "if it's there, use it, but otherwise, don't worry". Probably no such callers exist anymore, but complaining would be
a regression for them.-Peff
Jeff King <peff@peff.net>