Thread (67 messages) flat view 67 messages, 9 authors, 2016-08-07

Re: [PATCH v1 3/3] convert: add filter.<driver>.useProtocol option

From: Jakub Narębski <hidden>
Date: 2016-07-26 12:24:21

W dniu 2016-07-25 o 22:16, Lars Schneider pisze:
On 24 Jul 2016, at 23:30, Jakub Narębski [off-list ref] wrote:
quoted
W dniu 2016-07-24 o 22:14, Jakub Narębski pisze:
quoted
W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
quoted
quoted
I agree that the name is not ideal. "UseProtocol" as it is would be a boolean. 
I thought about "persistent" but this name wouldn't convey the scope of the 
persistency ("persistent for one Git operation" vs. "persistent for many Git 
operations"). What do you think about the protocol as int version idea
described in $gmane/300155 ?
You mean the `protocol` as a config variable name (fully name being
`filter.<driver>.protocol`), being integer-valued, isn't it? Wouldn't
`protocolVersion` be a more explicit?
Just throwing out further ideas:

Perhaps make `persistent` string-valued variable, with the only value
supported for now, namely "per-process" / "operation"?

Perhaps require for `pidfile` to be present for it to be daemon,
that is persist for possibly many Git operations. Or allow "daemon"
or "server" value for `persistent`, then?
I like the direction of this idea. What if we use a string-valued 
"filter.<driver>.protocol" with the following options:

"simple" / "invocation-per-file" / << empty >> --> current clean/smudge behavior
"invocation-per-process" --> new, proposed behavior

If necessary this could be enhanced in the future to support even a "daemon"
mode (with a pidfile config).
Though, after thinking about it, this solution has the problem
that people might think that they can use their old per-file
filters, just flipping the `filter.<driver>.protocol`.

I dunno.
-- 
Jakub Narębski
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help