Hello Phillip,
On 2024-06-09 16:29, phillip.wood123@xxxxxxxxx wrote:
On 08/06/2024 06:54, Dragan Simic wrote:
On 2024-06-05 15:21, Phillip Wood wrote:
On 05/06/2024 10:09, Jeff King wrote:
On Tue, Jun 04, 2024 at 08:32:04AM -0700, Junio C Hamano wrote:
Given that the main use case for "|" is for human viewing through a
pager, I think the colorful, filtered version meant for users is the
best default. And then the "bare" version can come from an alternate
command or a knob.
I think that's a very good point. It is hard to see what "|" can be
used for other than viewing the hunk as (a) git does not read the
output so it cannot be used to filter or edit the hunk that is
applied
and (b) we pass an isolated hunk so the post-image offset in the hunk
header is likely to be wrong and there is no indication as to which
file it comes from so the program being run cannot apply the hunk
itself. Having the escape codes does make it harder to filter the
hunk. For example to just look at the post-image as one needs to do
something like
grep '^[^-+ @]*[+ @]'
instead of just using '^[+ @]' as the pattern but the bonus is that
the output is colored.
Agreed, but as I already explained, [1] only when using the bare "|"
command. When "|xyz" is used instead, the version of the hunk with
no coloring escape sequences should be piped to xyz.
Having read the message you referenced I'm struggling to understand
the use-case for stripping escape codes - what do you want to do with
the hunk that means you want to remove the color?
Let me recap, please. Basically, when an output of some command is
piped into another command, e.g. by running "grep -r abc . | grep def",
the command that produces the piped output doesn't put the coloring
escape codes into the produced output, because it's unknown can the
command that receives it handle those escape codes properly. That's
become some kind of de facto standard embodied into the "--color=auto"
command-line option for various utilities.
In the example above, one can have "grep -n --color=auto" defined as
their alias for "grep", which is what I use, and the "grep -r abc"
produces the output with no coloring escape sequences, which gets
piped into "grep def" that does produce coloring escape codes, because
its output goes to the terminal emulator, which is expected to handle
those escape codes properly.
In our use case, Git becomes what produces a hunk as the output that
gets piped into some program "xyz" by receiving "|xyz" as the command
while "git add -p" is executed, but it isn't known can "xyz" handle
the coloring escape sequences properly, so they should not be included
in the piped output, i.e. in the produced hunk.
As discussed later, [2] we could introduce ">xyz" as another command
for "git add -p", so receiving ">xyz" from the user would pipe the
hunk to "xyz" with the coloring escape sequences included, because
the user already knows that "xyz" can handle them. Separating this
into two commands is a safe approach.
I hope this makes the whole thing more clear.
[1]
https://lore.kernel.org/git/844704794168f9fcb85c75014c84cde0@xxxxxxxxxxx/
[2]
https://lore.kernel.org/git/7937845d7cb7ae0179c4922ed154c5c7@xxxxxxxxxxx/
