Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > Thanks for all your comments. > > This is now built off "next" to include Lars's changes. > > About whether this is too restrictive (for example, as Junio mentions, > this will not allow future capabilities of the form "key=???"), I think > that this can be upgraded later if necessary. For now, both the filter > code and the ODB (and ODB-like) proposals on the mailing list do not > require such a thing, so I have not included that functionality. Heh, anything can be updated later. The real question is how much damage such an update may incur. If such an update ends up having to dismantle large part of what you did, then that is not a real consolation that it "can be" updated later. I think subprocess_handshake() can become the lowest level helper that takes callback function to act on the capability request that was received, and the existing user like start_multi_file_filter_fn() can be served by a thin-wrapper around subprocess_handshake() that defines a standard/built-in callback that checks the capability list for exact match and flips the bit in an unsigned, so it is possible to limit the damage when such an enhancement happens. > > Changes from v2: > - now rebased onto next, to pick up Lars's changes > - split up into more functions > - welcome prefix does not include final dash > - no more gotos in expected cases (or at all) > > Jonathan Tan (2): > Documentation: migrate sub-process docs to header > sub-process: refactor handshake to common function > > Documentation/technical/api-sub-process.txt | 59 ---------------- > convert.c | 75 ++------------------ > pkt-line.c | 19 ----- > pkt-line.h | 2 - > sub-process.c | 103 ++++++++++++++++++++++++++++ > sub-process.h | 51 +++++++++++++- > t/t0021-conversion.sh | 2 +- > 7 files changed, 160 insertions(+), 151 deletions(-) > delete mode 100644 Documentation/technical/api-sub-process.txt
