W dniu 2016-07-30 o 01:44, Lars Schneider pisze: > On 30 Jul 2016, at 01:11, Jakub Narębski <jnareb@xxxxxxxxx> wrote: >> I think the protocol should be either: <size> + <contents>, or >> <size unknown> + <contents> + <flush>, that is do not use flush >> packet if size is known upfront -- it would be a second point >> of truth (SPOT principle). > > As I mentioned elsewhere a <flush> packet is always send right now. > I have no strong opinion if this is good or bad. The implementation > was a little bit simpler and that's why I did it. I will implement > whatever option the majority prefers :-) Well, if we treat it as a size hint, then it is all right; as you say it makes for a simpler implementation: read till flush. Git should not error out if there is mismatch between specified and actual size of return from the filter; filter can do whatever it wants. I see there is v3 series sent, so I'll move the discussion there. One thing: we probably would want for the size / size-hint packet to be extensible, either size=<size> [(SPC <key>=<value>)...] "\n" or <size> [(SPC <sth>)...] "\n" that is, space separated list starting with size / size hint. Upfront error could be signalled by putting for example "error" in place of size, e.g. error <error description> "\n" -- Jakub Narębski -- 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