Re: receive.denyNonNonFastForwards not denying force update

[Jeff King <peff@peff.net>]

On Tue, Aug 21, 2012 at 09:50:27AM -0700, Junio C Hamano wrote:

> > 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