Re: [PATCH v10 13/14] convert: add filter.<driver>.process option
flat view
From: Jeff King <hidden>
Date: 2016-10-16 00:33:52
On Sat, Oct 15, 2016 at 07:45:48AM -0700, Lars Schneider wrote:
quoted
quoted
I have to agree that "capability=<capability>" might read a little bit nicer. However, Peff suggested "<capability>=true" as his preference and this is absolutely OK with me.From what I remember it was Peff stating that he thinks "<foo>=true" is easier for parsing (it is, but we still need to support the harder way parsing anyway), and offered that "<foo>" is good enough (if less consistent).
I don't mind that much if you want to do it the other way. You are the one writing the parsing/use code.
quoted
Also, with "capability=<foo>" we can be more self descriptive, for example "supported-command=<foo>"; though "capability" is good enough for me. For example packet: git> wants=clean packet: git> wants=smudge packet: git> wants=size packet: git> 0000 packet: git< supports=clean packet: git< supports=smudge packet: git< 0000 Though coming up with good names is hard; and as I said "capability" is good enough; OTOH with "smudge=true" etc. we don't need to come up with good name at all... though I wonder if it is a good thing `\_o,_/How about this (I borrowed these terms from contract negotiation)? packet: git> offers=clean packet: git> offers=smudge packet: git> offers=size packet: git> 0000 packet: git< accepts=clean packet: git< accepts=smudge packet: git< 0000 @Peff: Would that be OK for you?
Is it always an offers/accepts relationship? Can the response say "you did not ask about <foo>, but just so you know I support it"? I cannot think offhand of an example, but at the same time, if you leave the terms as generic as possible, you do not end up later with words that do not make sense. It is trading off one problem now (vagueness of the protocol terms) for a potential one later (words that have a specific meaning, but one that is not accurate). I don't have a strong preference, though. -Peff