[PATCH/RFC] ignore unknown color configuration

[PATCH/RFC] ignore unknown color configuration

[Jeff King]

When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).

The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.

However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.

This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.

Signed-off-by: Jeff King <peff@peff.net>
---
I don't know if it is worth trying to fix the problem for
color.diff.func. It would require renaming the variable to something
outside of the color.diff hierarchy, which is quite ugly. I don't know
how common a problem this is. Personally I switch between git versions a
lot doing git development (uncommon), but I also ran into it because I
share my ~/.gitconfig across several machines (which may be much more
common).

I suppose we could provide an undocumented alias of "color.difffunc",
and then only people who ran into this problem would have to be exposed
to the monstrosity. Normal people would use color.diff.func and be none
the wiser. But that feels awfully hack-ish to me.

 builtin-branch.c |    4 +++-
 builtin-commit.c |    4 +++-
 diff.c           |    4 +++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/builtin-branch.c b/builtin-branch.c
index 05e876e..c87e63b 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -65,7 +65,7 @@ static int parse_branch_color_slot(const char *var, int ofs)
 		return BRANCH_COLOR_LOCAL;
 	if (!strcasecmp(var+ofs, "current"))
 		return BRANCH_COLOR_CURRENT;
-	die("bad config variable '%s'", var);
+	return -1;
 }
 
 static int git_branch_config(const char *var, const char *value, void *cb)
@@ -76,6 +76,8 @@ static int git_branch_config(const char *var, const char *value, void *cb)
 	}
 	if (!prefixcmp(var, "color.branch.")) {
 		int slot = parse_branch_color_slot(var, 13);
+		if (slot < 0)
+			return 0;
 		if (!value)
 			return config_error_nonbool(var);
 		color_parse(value, var, branch_colors[slot]);
diff --git a/builtin-commit.c b/builtin-commit.c
index e93a647..326cd63 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -890,7 +890,7 @@ static int parse_status_slot(const char *var, int offset)
 		return WT_STATUS_NOBRANCH;
 	if (!strcasecmp(var+offset, "unmerged"))
 		return WT_STATUS_UNMERGED;
-	die("bad config variable '%s'", var);
+	return -1;
 }
 
 static int git_status_config(const char *k, const char *v, void *cb)
@@ -910,6 +910,8 @@ static int git_status_config(const char *k, const char *v, void *cb)
 	}
 	if (!prefixcmp(k, "status.color.") || !prefixcmp(k, "color.status.")) {
 		int slot = parse_status_slot(k, 13);
+		if (slot < 0)
+			return -1;
 		if (!v)
 			return config_error_nonbool(k);
 		color_parse(v, k, s->color_palette[slot]);
diff --git a/diff.c b/diff.c
index d952686..08bbd3e 100644
--- a/diff.c
+++ b/diff.c
@@ -63,7 +63,7 @@ static int parse_diff_color_slot(const char *var, int ofs)
 		return DIFF_WHITESPACE;
 	if (!strcasecmp(var+ofs, "func"))
 		return DIFF_FUNCINFO;
-	die("bad config variable '%s'", var);
+	return -1;
 }
 
 static int git_config_rename(const char *var, const char *value)
@@ -122,6 +122,8 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
 
 	if (!prefixcmp(var, "diff.color.") || !prefixcmp(var, "color.diff.")) {
 		int slot = parse_diff_color_slot(var, 11);
+		if (slot < 0)
+			return 0;
 		if (!value)
 			return config_error_nonbool(var);
 		color_parse(value, var, diff_colors[slot]);
-- 
1.6.6.rc2.18.gbc86b8

Re: [PATCH/RFC] ignore unknown color configuration

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> When parsing the config file, if there is a value that is
> syntactically correct but unused, we generally ignore it.
> This lets non-core porcelains store arbitrary information in
> the config file, and it means that configuration files can
> be shared between new and old versions of git (the old
> versions might simply ignore certain configuration).
>
> The one exception to this is color configuration; if we
> encounter a color.{diff,branch,status}.$slot variable, we
> die if it is not one of the recognized slots (presumably as
> a safety valve for user misconfiguration).

This reminds me of the issue an earlier patch with a good intention but a
horrible consequence wanted to address.

  http://thread.gmane.org/gmane.comp.version-control.git/125925/focus=127629

> This patch loosens the check to match the rest of
> git-config; unknown color slots are simply ignored.

I am of two minds, even though I am slightly in favor than against the
change.

This is a sane thing to do, as "slot" is part of the name of the variable,
and we generally do not warn upon seeing a misspelled variable name (it
makes it worse that "func" is not even misspelled but merely unknown to
older version of git in your scenario).

On the other hand, I suspect that most people would apprecfiate if their
git pointed out "diff.color.finc?  What do you mean?"  before they waste
30 minutes wondering why the new feature in 1.6.6 does not work for them.

Re: [PATCH/RFC] ignore unknown color configuration

[Jeff King]

On Sat, Dec 12, 2009 at 01:45:45PM -0800, Junio C Hamano wrote:

> This is a sane thing to do, as "slot" is part of the name of the variable,
> and we generally do not warn upon seeing a misspelled variable name (it
> makes it worse that "func" is not even misspelled but merely unknown to
> older version of git in your scenario).
> 
> On the other hand, I suspect that most people would apprecfiate if their
> git pointed out "diff.color.finc?  What do you mean?"  before they waste
> 30 minutes wondering why the new feature in 1.6.6 does not work for them.

I would be more sympathetic to that user if this weren't the _only_ set
of variables with this property. They don't get warned for diff.externel
or color.show-branch.

If we are going to declare subsets of the namespace as "complete" (and
warn about unknown keys in them), then we should probably be more
thorough about it (but I don't personally think that is a good idea, as
version portability is IMHO more useful).

-Peff

Re: [PATCH/RFC] ignore unknown color configuration

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Sat, Dec 12, 2009 at 01:45:45PM -0800, Junio C Hamano wrote:
>
>> This is a sane thing to do, as "slot" is part of the name of the variable,
>> and we generally do not warn upon seeing a misspelled variable name (it
>> makes it worse that "func" is not even misspelled but merely unknown to
>> older version of git in your scenario).
>> 
>> On the other hand, I suspect that most people would apprecfiate if their
>> git pointed out "diff.color.finc?  What do you mean?"  before they waste
>> 30 minutes wondering why the new feature in 1.6.6 does not work for them.
>
> I would be more sympathetic to that user if this weren't the _only_ set
> of variables with this property. They don't get warned for diff.externel
> or color.show-branch.

True and fair enough.  Let's have this in 1.6.6 then.

Re: [PATCH/RFC] ignore unknown color configuration

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Jeff King <peff@peff.net> writes:
>
>> On Sat, Dec 12, 2009 at 01:45:45PM -0800, Junio C Hamano wrote:
>>
>>> This is a sane thing to do, as "slot" is part of the name of the variable,
>>> and we generally do not warn upon seeing a misspelled variable name (it
>>> makes it worse that "func" is not even misspelled but merely unknown to
>>> older version of git in your scenario).
>>> 
>>> On the other hand, I suspect that most people would apprecfiate if their
>>> git pointed out "diff.color.finc?  What do you mean?"  before they waste
>>> 30 minutes wondering why the new feature in 1.6.6 does not work for them.
>>
>> I would be more sympathetic to that user if this weren't the _only_ set
>> of variables with this property. They don't get warned for diff.externel
>> or color.show-branch.
>
> True and fair enough.  Let's have this in 1.6.6 then.

Actually I think we should have this in 1.6.5.X as well for it to be
useful.  Am I mistaken?

Re: [PATCH/RFC] ignore unknown color configuration

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> diff --git a/builtin-branch.c b/builtin-branch.c
> index 05e876e..c87e63b 100644
> --- a/builtin-branch.c
> +++ b/builtin-branch.c
> @@ -65,7 +65,7 @@ static int parse_branch_color_slot(const char *var, int ofs)
>  		return BRANCH_COLOR_LOCAL;
>  	if (!strcasecmp(var+ofs, "current"))
>  		return BRANCH_COLOR_CURRENT;
> -	die("bad config variable '%s'", var);
> +	return -1;
>  }
>  
>  static int git_branch_config(const char *var, const char *value, void *cb)
> @@ -76,6 +76,8 @@ static int git_branch_config(const char *var, const char *value, void *cb)
>  	}
>  	if (!prefixcmp(var, "color.branch.")) {
>  		int slot = parse_branch_color_slot(var, 13);
> +		if (slot < 0)
> +			return 0;
>  		if (!value)
>  			return config_error_nonbool(var);
>  		color_parse(value, var, branch_colors[slot]);
> diff --git a/builtin-commit.c b/builtin-commit.c
> index e93a647..326cd63 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -890,7 +890,7 @@ static int parse_status_slot(const char *var, int offset)
>  		return WT_STATUS_NOBRANCH;
>  	if (!strcasecmp(var+offset, "unmerged"))
>  		return WT_STATUS_UNMERGED;
> -	die("bad config variable '%s'", var);
> +	return -1;
>  }
>  
>  static int git_status_config(const char *k, const char *v, void *cb)
> @@ -910,6 +910,8 @@ static int git_status_config(const char *k, const char *v, void *cb)
>  	}
>  	if (!prefixcmp(k, "status.color.") || !prefixcmp(k, "color.status.")) {
>  		int slot = parse_status_slot(k, 13);
> +		if (slot < 0)
> +			return -1;

Shouldn't this return 0, to say "we handled it (by ignoring), don't
worry", instead of saying "hey it's error" by returning -1?  That's what
is done on the "diff" side below...

> diff --git a/diff.c b/diff.c
> index d952686..08bbd3e 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -122,6 +122,8 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
>  
>  	if (!prefixcmp(var, "diff.color.") || !prefixcmp(var, "color.diff.")) {
>  		int slot = parse_diff_color_slot(var, 11);
> +		if (slot < 0)
> +			return 0;
>  		if (!value)
>  			return config_error_nonbool(var);
>  		color_parse(value, var, diff_colors[slot]);

Re: [PATCH/RFC] ignore unknown color configuration

[Jeff King]

On Tue, Dec 15, 2009 at 05:25:36PM -0800, Junio C Hamano wrote:

> >> I would be more sympathetic to that user if this weren't the _only_ set
> >> of variables with this property. They don't get warned for diff.externel
> >> or color.show-branch.
> >
> > True and fair enough.  Let's have this in 1.6.6 then.
> 
> Actually I think we should have this in 1.6.5.X as well for it to be
> useful.  Am I mistaken?

The earlier the better for making it useful, but it is still somewhat of
a lost cause for color.diff.func. The problem comes from using git
v1.6.6, setting the variable, and then going to back to some older
version (either because you are testing multiple versions, or because
your config is shared across multiple machines).

So yes, putting it in v1.6.5.x means switching back there will not be as
painful. But switching back to existing versions will still be broken
until all older versions you might want to switch to have this patch.

So we are not so much fixing this color.diff.func problem as
future-proofing against this happening again.

-Peff

Re: [PATCH/RFC] ignore unknown color configuration

[Jeff King]

On Tue, Dec 15, 2009 at 05:29:18PM -0800, Junio C Hamano wrote:

> >  	if (!prefixcmp(k, "status.color.") || !prefixcmp(k, "color.status.")) {
> >  		int slot = parse_status_slot(k, 13);
> > +		if (slot < 0)
> > +			return -1;
> 
> Shouldn't this return 0, to say "we handled it (by ignoring), don't
> worry", instead of saying "hey it's error" by returning -1?  That's what
> is done on the "diff" side below...

Yes, thank you for catching it. It should definitely be "return 0" (as
the other two cases are). It was a simple think-o on my part.

-Peff