threads / rfc / 21943

RFC patchignore unknown color configuration

Subject: [PATCH/RFC] ignore unknown color configuration

## tl;dr

8 messages between Dec 12, 2009 and Dec 16, 2009. Diffs are folded; open one to read it.

replies: 7people: 2as markdown or json

Jeff King· Dec 12, 2009, 12:25 UTC · lore

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(-)
Show changes to 3 files +9 −3

builtin-branch.c, builtin-commit.c, diff.c

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
Junio C Hamano· Dec 12, 2009, 21:45 UTC · re: Jeff King · lore

Re: [PATCH/RFC] ignore unknown color configuration

Jeff King <peff@peff.net> writes:
Show 11 quoted lines
> 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.

Jeff King· Dec 12, 2009, 22:20 UTC · re: Junio C Hamano · lore

Re: [PATCH/RFC] ignore unknown color configuration

On Sat, Dec 12, 2009 at 01:45:45PM -0800, Junio C Hamano wrote:
Show 8 quoted lines
> 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
Junio C Hamano· Dec 14, 2009, 02:33 UTC · re: Jeff King · lore

Re: [PATCH/RFC] ignore unknown color configuration

Jeff King <peff@peff.net> writes:
Show 14 quoted lines
> 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.
Junio C Hamano· Dec 16, 2009, 01:25 UTC · re: Junio C Hamano · lore

Re: [PATCH/RFC] ignore unknown color configuration

Junio C Hamano <gitster@pobox.com> writes:
Show 18 quoted lines
> 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?

Jeff King· Dec 16, 2009, 03:45 UTC · re: Junio C Hamano · lore

Re: [PATCH/RFC] ignore unknown color configuration

On Tue, Dec 15, 2009 at 05:25:36PM -0800, Junio C Hamano wrote:
Show 8 quoted lines
> >> 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
Junio C Hamano· Dec 16, 2009, 01:29 UTC · re: Jeff King · lore

Re: [PATCH/RFC] ignore unknown color configuration

Jeff King <peff@peff.net> writes:
Show 41 quoted lines
> 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...

Show 13 quoted lines
> 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]);
Jeff King· Dec 16, 2009, 03:46 UTC · re: Junio C Hamano · lore

Re: [PATCH/RFC] ignore unknown color configuration

On Tue, Dec 15, 2009 at 05:29:18PM -0800, Junio C Hamano wrote:
Show 8 quoted lines
> >  	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

← back to recent threads