Stefan Beller [off-list ref] writes:
And we want to have both "label=A B C" and attr:label=A B C" or *just* the
attr query?
I think the choice at this point is between supporting just "label=A
B C" or supporting just "attr:eol=crlf text=auto !diff".
I think "attr:label=A" is merely a degenerated case of the latter.
We should not allow the user to add arbitrary attributes (i.e. labels).
Hmph, why not?
Instead each of the "attr for labeling purposes" needs to follow a clear scheme
that allows us to add attributes later on that are outside of that scheme.
That was my initial reaction when I saw Duy's "attr:crlf=auto" (by
the way, there is no such setting; crlf should be one of TRUE, UNSET
or set to string "input") idea. But I do not think of a good
argument to justify that arbitrary attributes are not allowed.
On Mon, May 16, 2016 at 2:50 PM, Junio C Hamano [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
And we want to have both "label=A B C" and attr:label=A B C" or *just* the
attr query?
I think the choice at this point is between supporting just "label=A
B C" or supporting just "attr:eol=crlf text=auto !diff".
I think "attr:label=A" is merely a degenerated case of the latter.
quoted
We should not allow the user to add arbitrary attributes (i.e. labels).
Because we cannot extend our attributes any further from that?
Consider a user starts using attr <foo> for their labeling purposes.
Later (in 2 years) we decide that <foo> is an attribute we want to
use to mark files as foo-ish. so we add meaning to that attribute
(just like eol.crlf does an arbitrary thing, foo would do another arbitrary
thing).
Then the user picks up the new version of Git and expects <foo> to
still be a "I use it for labeling purposes only" thing. They would not
expect to all files labeled as <foo> to start behaving <foo-ish> ?
Hmph, why not?
We need a namespace for which
* we can guarantee that it is for labeling purposes only (even in the future)
* is obvious to the user to be a labeling name space
Starting with "label" offers both?
quoted
Instead each of the "attr for labeling purposes" needs to follow a clear scheme
that allows us to add attributes later on that are outside of that scheme.
That was my initial reaction when I saw Duy's "attr:crlf=auto" (by
the way, there is no such setting; crlf should be one of TRUE, UNSET
or set to string "input") idea. But I do not think of a good
argument to justify that arbitrary attributes are not allowed.
I agree that querying for attr:eol or attr:diff is a good idea.
I do however want to point out that all labels for "labeling purposes"
MUST be a clear from the beginning, otherwise we'll have the maintenance
problem down the road?