Re: [PATCH] builtin/blame: ignore nonexistent ignore files

[Junio C Hamano <gitster@pobox.com>]

"jade via GitGitGadget" <gitgitgadget@gmail.com> writes:

> It's currently a problem to put blame.ignoreRevsFile in a global
> gitconfig, for example, to use the GitHub (and other) supported filename
> of .git-blame-ignore-revs by default if present in a repo, since the
> current implementation exits the process if it fails to open the file.

Well, that is how it is designed to be used.  If the file you
specify does not exist, it is likely you made a typo, which you
would want to be told about.

I however am somewhat sympathetic to the cause.  If the user had a
way to tell Git that they know what they are doing, it would make
sense in certain situations to allow the paths they specify, either
from the command line or in the configuration files, to be optional,
without triggering "no, there is no such file, perhaps you have a
typo there?" error.

Having said all that, I am not interested in the design and
implementaion presented in this patch at all, for many reasons.

 - The code essentially duplicates the loop that goes over the
   specified files.

 - Unconditionally robbing the typo protection from existing users
   who expect the command would refuse to start when they
   misconfigure is not absolute no-no.  We would have some way for
   the user to say "I am giving this path to be used, but this is
   optional. Instead of failing, just pretend I didn't specify it if
   it does not exist".

 - Singling out the ignorefile configuration and treating it
   differently from the command line option makes things
   inconsistent.  Perhaps people may want to do

    [alias] fooblame = blame --ignore-revs-file="foo"
    [alias] barblame = blame --ignore-revs-file="bar"

   instead of using a single configuration variable, and somehow
   want to mark them to be "optional".

 - The situation where users want to specify a pathname for a file
   that is optional is not limited to blame.ignoreRevsFile.  Any
   codepath that takes user-specified/specifiable pathname (or blob
   object name) should benefit if we had a single consistent way to
   tell Git that the path is optional.

An alternative design that goes along the following lines may be
more palatable:

 - The way to spell for the users to specify a path that is
   optional, either as the value of a command line option or a
   configuration variable, is to prefix it with ":(optional)".  E.g.

    [blame]
	ignoreRevsFile = ":(optional).git-blame-ignore"

    $ git blame --ignore-revs-file=":(optional).git-blame-ignore"

 - For command line options, all commands that use parse-options API
   would automatically benefit by updating parse-options.c and tweak
   its handling of OPTION_FILENAME; when the specified string begins
   with ":(optional)", you strip the prefix and see if the remainder
   or the string names an existing file.  If it does, you use the
   filename as the value of that command line option; otherwise you
   pretend that the option didn't even exist on the command line.

 - For configuration variables, you update git_config_pathname() to
   do the same.

Thanks.