Jeff King <peff@xxxxxxxx> writes:
>> This option enables a straightforward implementation of a `git sed`:
>>
>> #!/bin/bash
>> git ls-files --exclude-links -z | xargs -0 -P $(nproc) -- sed -i -e "$@"
Unrelated nit.
I think -i -e above is iffy, as it does not distribute -e across
"$@" and your users may not always want to edit the files. It is
better to leave them to the callers.
"sed" is also something the caller can easily pass from their
command line, for that matter ;-). Passing the entire command
part run under xargs from the command line of the wrapper,
$ git for-all-paths grep -e pattern
would also work just fine, for example.
> ... A mild application of perl works, though:
>
> git ls-files -s -z |
> perl -0ne 'print if s/^100(644|755).*?\t//' |
> xargs -0 ...
>
> So I dunno. That is not exactly pretty, but if you were hiding it in a
> "git sed" alias or script, it's not so bad.
Yes, the above would be a perfectly reasonable implementation of
"git for-all-paths", especially if you do not hardcode anything in
the ... part and instead use something like xargs -0 "$@" there.
What is somewhat unsatisfactory is that we cannot pass pathspec to
the "ls-files" so that the command does not have to be for-all-paths
but can be usable as "git do-for-paths -c '<command>' <pathspec>".
