On Mon, May 16, 2016 at 2:50 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> 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). 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? > >> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html