Re: What's cooking in git.git (Oct 2016, #04; Mon, 17)

Lars Schneider [off-list ref] writes:

quoted

On 17 Oct 2016, at 15:28, Junio C Hamano [off-list ref] wrote:
...

* ls/filter-process (2016-10-17) 14 commits
- contrib/long-running-filter: add long running filter example
- convert: add filter.<driver>.process option
- convert: prepare filter.<driver>.process option
- convert: make apply_filter() adhere to standard Git error handling
- pkt-line: add functions to read/write flush terminated packet streams
- pkt-line: add packet_write_gently()
- pkt-line: add packet_flush_gently()
- pkt-line: add packet_write_fmt_gently()
- pkt-line: extract set_packet_header()
- pkt-line: rename packet_write() to packet_write_fmt()
- run-command: add clean_on_exit_handler
- run-command: move check_pipe() from write_or_die to run_command
- convert: modernize tests
- convert: quote filter names in error messages

The smudge/clean filter API expect an external process is spawned
to filter the contents for each path that has a filter defined.  A
new type of "process" filter API has been added to allow the first
request to run the filter for a path to spawn a single process, and
all filtering need is served by this single process for multiple
paths, reducing the process creation overhead.

Hi Junio,

what do you think about v11? Do you feel the series is becoming mature
enough for `next`?

I've already had that feeling a few rounds ago, but I haven't had a
chance to read the most recent one carefully myself to answer that
question honestly.

On Tue, Oct 18, 2016 at 01:31:27PM -0700, Junio C Hamano wrote:

quoted

quoted

* ls/filter-process (2016-10-17) 14 commits

[...]

quoted

what do you think about v11? Do you feel the series is becoming mature
enough for `next`?

I've already had that feeling a few rounds ago, but I haven't had a
chance to read the most recent one carefully myself to answer that
question honestly.

FWIW, I gave it a fairly thorough read-over (something I'd been meaning
to do for quite a while, but kept never quite getting around to). I
think overall it is OK for next. I did find one or two nits, but I think
they are things we can fix up in-tree if and when they become a problem
(e.g., I noticed that test-genrandom gets piped to "perl -pe". I'm not
sure if perl will complain about funny multibyte characters on some
systems. I suggest we ignore it until somebody demonstrates that it
actually matters).

-Peff

On Wed, Oct 19, 2016 at 03:46:48AM -0400, Jeff King wrote:

FWIW, I gave it a fairly thorough read-over (something I'd been meaning
to do for quite a while, but kept never quite getting around to). I
think overall it is OK for next. I did find one or two nits, but I think
they are things we can fix up in-tree if and when they become a problem
(e.g., I noticed that test-genrandom gets piped to "perl -pe". I'm not
sure if perl will complain about funny multibyte characters on some
systems. I suggest we ignore it until somebody demonstrates that it
actually matters).

I just looked, and that use is fine.  perl -pe is always going to treat
its data as bytes unless you use -C or explicitly enable Unicode
functionality.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

On Wed, Oct 19, 2016 at 08:28:56PM +0000, brian m. carlson wrote:

On Wed, Oct 19, 2016 at 03:46:48AM -0400, Jeff King wrote:

quoted

FWIW, I gave it a fairly thorough read-over (something I'd been meaning
to do for quite a while, but kept never quite getting around to). I
think overall it is OK for next. I did find one or two nits, but I think
they are things we can fix up in-tree if and when they become a problem
(e.g., I noticed that test-genrandom gets piped to "perl -pe". I'm not
sure if perl will complain about funny multibyte characters on some
systems. I suggest we ignore it until somebody demonstrates that it
actually matters).

I just looked, and that use is fine.  perl -pe is always going to treat
its data as bytes unless you use -C or explicitly enable Unicode
functionality.

Thanks. I have vague memories of multibyte warnings, but I think they
may have been on _output_ when passing through binary data that came
on stdin.

-Peff