From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Gerrit Pape <pape@smarden.org>
Subject: Re: [PATCH v2 1/8] config: Trivial rename in preparation for parseopt.
Date: Tue, 17 Feb 2009 04:42:38 +0200 [thread overview]
Message-ID: <94a0d4530902161842s1d1d9fech3786cce1f1a1135d@mail.gmail.com> (raw)
In-Reply-To: <7v3aedet0j.fsf@gitster.siamese.dyndns.org>
On Tue, Feb 17, 2009 at 3:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> When using the --list option general errors where not properly reported,
>> only errors related with the 'file'. Now they are reported, and 'file'
>> is irrelevant.
>> ...
>> @@ -299,10 +300,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
>> else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l")) {
>> if (argc != 2)
>> usage(git_config_set_usage);
>> - if (git_config(show_all_config, NULL) < 0 &&
>> - file && errno)
>> - die("unable to read config file %s: %s", file,
>> - strerror(errno));
>> + if (git_config(show_all_config, NULL) < 0)
>> + die("error processing config file(s)");
>
> Does the author of 93a56c2 (git-config: print error message if the config
> file cannot be read, 2007-10-12) have any comment on this change (cc:ed)?
I looked at the debian bug report[1], the guy complains about 2 things:
1) git-config --file fails silently if the filename isn't absolute
This is still fixed.
2) git-config -l --file doesn't do what you might expect and list the
contents of the specified file. Instead it ignores the --file option since it
came after the -l. Nice way to shoot oneself in the foot.
This is now fixed after the parseopt patch.
Also, before this patch 'git config --global -l' would fail silently
if there isn't any ~/.gitconfig. Now at least git reports "error
processing config file(s)".
A more ideal solution would be:
if (config_exclusive_filename)
die("unable to read config file %s: %s",
config_exclusive_filename, strerror(errno));
else
die("error processing config file(s)");
So, if a file is specified with --file, --global, or --system, then
the correct error would be reported.
I digged a bit more and it turns out if there's parse error
git_config() will die immediately, and the only time it will return a
negative value is when the config file(s) are not present, at which
point there will be an errno set, and when config_exclusive_filename
is specified that means the errno will be the one of fopen trying to
open that file.
Still, "error processing config file(s)" will be reported when no file
is specified 'git config -l', there isn't any repo config file (cwd is
not in a git repo).
Even better I think would be to allow 'git config -l' to work even if
we are not in a git repo, and error only when there isn't any config
file (repo, system or global).
This is how it would look like:
int git_config(config_fn_t fn, void *data)
{
- int ret = 0;
+ int ret = 0, found = 0;
char *repo_config = NULL;
const char *home = NULL;
/* Setting $GIT_CONFIG makes git read _only_ the given config file. */
if (config_exclusive_filename)
return git_config_from_file(fn,
config_exclusive_filename, data);
- if (git_config_system() && !access(git_etc_gitconfig(), R_OK))
+ if (git_config_system() && !access(git_etc_gitconfig(), R_OK)) {
ret += git_config_from_file(fn, git_etc_gitconfig(),
data);
+ found += 1;
+ }
home = getenv("HOME");
if (git_config_global() && home) {
char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
- if (!access(user_config, R_OK))
+ if (!access(user_config, R_OK)) {
ret += git_config_from_file(fn, user_config, data);
+ found += 1;
+ }
free(user_config);
}
repo_config = git_pathdup("config");
- ret += git_config_from_file(fn, repo_config, data);
+ if (!access(repo_config, R_OK)) {
+ ret += git_config_from_file(fn, repo_config, data);
+ found += 1;
+ }
free(repo_config);
+ if (found == 0)
+ error("no config file found");
return ret;
}
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445208
--
Felipe Contreras
next prev parent reply other threads:[~2009-02-17 2:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-17 0:54 [PATCH v2 1/8] config: Trivial rename in preparation for parseopt Felipe Contreras
2009-02-17 0:54 ` [PATCH v2 2/8] config: Reorganize get_color* Felipe Contreras
2009-02-17 0:54 ` [PATCH v2 3/8] config: Use parseopt Felipe Contreras
2009-02-17 0:54 ` [PATCH v2 4/8] config: Disallow multiple variable types Felipe Contreras
2009-02-17 0:54 ` [PATCH v2 5/8] config: Disallow multiple config file locations Felipe Contreras
2009-02-17 0:54 ` [PATCH v2 6/8] config: Don't allow extra arguments for -e or -l Felipe Contreras
2009-02-17 0:54 ` [PATCH v2 7/8] config: Codestyle cleanups Felipe Contreras
2009-02-17 0:54 ` [PATCH v2 8/8] config: Cleanup editor action Felipe Contreras
2009-02-17 2:28 ` Junio C Hamano
2009-02-17 2:24 ` [PATCH v2 4/8] config: Disallow multiple variable types Junio C Hamano
2009-02-17 2:24 ` [PATCH v2 3/8] config: Use parseopt Junio C Hamano
2009-02-17 13:55 ` Felipe Contreras
2009-02-17 5:44 ` Junio C Hamano
2009-02-17 10:35 ` Felipe Contreras
2009-02-17 11:55 ` Johannes Schindelin
2009-02-17 13:21 ` Felipe Contreras
2009-02-17 1:00 ` [PATCH v2 2/8] config: Reorganize get_color* Felipe Contreras
2009-02-17 2:24 ` Junio C Hamano
2009-02-17 1:45 ` [PATCH v2 1/8] config: Trivial rename in preparation for parseopt Junio C Hamano
2009-02-17 2:42 ` Felipe Contreras [this message]
2009-02-17 12:01 ` Johannes Schindelin
2009-02-17 13:59 ` Felipe Contreras
2009-02-17 9:00 ` Gerrit Pape
2009-02-17 11:58 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94a0d4530902161842s1d1d9fech3786cce1f1a1135d@mail.gmail.com \
--to=felipe.contreras@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pape@smarden.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).