"jade via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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.
