Re: [PATCH v10 6/9] convert: add 'working-tree-encoding' attribute

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 7, 2018, 19:35 UTC
Message-ID: <xmqqvae7znkj.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180307173026.30058-7-lars.schneider@autodesk.com>

lars.schneider@autodesk.com writes:

Show 7 quoted lines

> +static const char *git_path_check_encoding(struct attr_check_item *check)
> +{
> +	const char *value = check->value;
> +
> +	if (ATTR_TRUE(value) || ATTR_FALSE(value) || ATTR_UNSET(value) ||
> +	    !strlen(value))
> +		return NULL;

This means that having "* working-tree-encoding" (without "=value") in your .gitattributes file is silently ignored.

Thinking aloud. I wonder if that is something we would want to warn about so that the project can fix it, perhaps? Or would that become too noisy to use an older version of Git that includes this series when a newer version that defines new meanings to boolean (set/unset) values for w-t-e attribute becomes available and projects adopt it? On the other hand, with this code as-is or with an additional warning, such an "older version" of Git by definition behaves differently from such a "newer version" that does something different when the attribute is not a non-empty string, so it is quite likely that we won't be able to redefine or extend the meaning of w-t-e in a way like that.

Which means that the only sensible way to make sure we _could_ later extend the meaning of w-t-e and make it behave differently when set to a non-empty string is to make it an error in _this_ "older" version. That way, of course people cannot use the "older" version on a newer project that depends on the way how "newer" Git treats w-t-e that is set to, say, "true", but we won't silently (or loudly) do wrong things to the project's data.