Stefan Beller <[email protected]> writes:
> So "warn and ignore" for data from .gitattributes and die for
> commandline arguments? That makes sense.
Yes.
On the "command line" front, because we may want to give different
meanings to these two entries in the future:
:(label=-doc)Documentation/
:(label=!doc)Documentation/
we should diagnose -doc (FALSE) as an error, not treating it as the
same as !doc (UNSET). And we should warn and ignore -doc (FALSE) in
.gitattributes. Yes, ignoring it would be more or less equivalent
to treating it as UNSET, but because we may use -doc (FALSE) for a
better purpose later, we should still warn.
> Ok, so here is the warn-and-ignore code:
>
>
> if (ATTR_TRUE(check.value))
> ret = 1; /* has all the labels */
> else if (ATTR_FALSE(check.value)) {
> warning(_("Path '%s': Label must not be false. Treat
> as if no label was set"), path);
> ret = 0;
s/Treat as if .../The -label may be used differently in future
versions of Git, so do not use it/;
But if we are going in the direction of :(attr:crlf=auto), all this
discussion is moot, isn't it? I haven't formed a firm opinion on
this, but it sure does sound tempting, doesn't it?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
