* bug#58199: 29.0.50; Odd "git pull" output
@ 2022-09-30 18:21 Lars Ingebrigtsen
2022-09-30 18:40 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-30 18:21 UTC (permalink / raw)
To: 58199
[-- Attachment #1: Type: text/plain, Size: 138 bytes --]
When doing a `+' in a vc-dir buffer, a buffer is popped up displaying
the output from "git pull". It usually ends something like this:
[-- Attachment #2: Type: image/png, Size: 53460 bytes --]
[-- Attachment #3: Type: text/plain, Size: 566 bytes --]
Those ^M characters look ugly. Should the filter process here do
something about those? Or are they part of some ANSI control character
sequence that's not parsed correctly, perhaps?
In GNU Emacs 29.0.50 (build 46, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0) of 2022-09-29 built on downe
Repository revision: 48c9f9d31d3eab756595c05cd2d3aced0fd856ca
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Ubuntu 22.04.1 LTS
Configured using:
'configure --with-xwidgets'
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58199: 29.0.50; Odd "git pull" output
2022-09-30 18:21 bug#58199: 29.0.50; Odd "git pull" output Lars Ingebrigtsen
@ 2022-09-30 18:40 ` Eli Zaretskii
2022-10-01 13:37 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-09-30 18:40 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 58199
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 30 Sep 2022 20:21:20 +0200
>
> Those ^M characters look ugly. Should the filter process here do
> something about those? Or are they part of some ANSI control character
> sequence that's not parsed correctly, perhaps?
No ANSI control sequences: that's Git overwriting its own output with
later output, for aesthetic reasons. We should convert those ^M
characters to newline, I think.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58199: 29.0.50; Odd "git pull" output
2022-09-30 18:40 ` Eli Zaretskii
@ 2022-10-01 13:37 ` Lars Ingebrigtsen
2022-10-01 13:41 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-01 13:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 58199
Eli Zaretskii <eliz@gnu.org> writes:
>> Those ^M characters look ugly. Should the filter process here do
>> something about those? Or are they part of some ANSI control character
>> sequence that's not parsed correctly, perhaps?
>
> No ANSI control sequences: that's Git overwriting its own output with
> later output, for aesthetic reasons. We should convert those ^M
> characters to newline, I think.
Right.
Hm... looking at the VC code, I see that vc-do-command sets a filter
`vc-process-filter' that's trivial -- I had expected that there would be
some mangling of the output already in there somewhere...
Oh, OK, I see that the backends do stuff like
(add-function :around (process-filter proc)
#'vc-cvs-annotate-process-filter)
so I guess the fix here would be to make vc-git-pull do something
similar.
I'll give it a go.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58199: 29.0.50; Odd "git pull" output
2022-10-01 13:37 ` Lars Ingebrigtsen
@ 2022-10-01 13:41 ` Lars Ingebrigtsen
2022-10-01 13:52 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-01 13:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 58199
Alternatively, if there was some way to make "git pull" not do stuff
like that in the output, that would be even simpler. But the only thing
I find is:
--progress
Progress status is reported on the standard error stream by default
when it is attached to a terminal, unless -q is specified. This
flag forces progress status even if the standard error stream is
not directed to a terminal.
And we don't want "-q" -- we just don't want the progress output, I
guess, and that can't be disabled separately.
But I may be missing something -- anybody know?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58199: 29.0.50; Odd "git pull" output
2022-10-01 13:41 ` Lars Ingebrigtsen
@ 2022-10-01 13:52 ` Eli Zaretskii
2022-10-01 14:08 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-10-01 13:52 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 58199
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 58199@debbugs.gnu.org
> Date: Sat, 01 Oct 2022 15:41:48 +0200
>
> Alternatively, if there was some way to make "git pull" not do stuff
> like that in the output, that would be even simpler. But the only thing
> I find is:
>
> --progress
> Progress status is reported on the standard error stream by default
> when it is attached to a terminal, unless -q is specified. This
> flag forces progress status even if the standard error stream is
> not directed to a terminal.
>
> And we don't want "-q" -- we just don't want the progress output, I
> guess, and that can't be disabled separately.
>
> But I may be missing something -- anybody know?
Would it work if we force the process connection to use pipes?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58199: 29.0.50; Odd "git pull" output
2022-10-01 13:52 ` Eli Zaretskii
@ 2022-10-01 14:08 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-01 14:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 58199
Eli Zaretskii <eliz@gnu.org> writes:
> Would it work if we force the process connection to use pipes?
From my reading of the manual page -- yes, it would. However, the "git
pull" is started by the general vc-do-async-command function (which is
used for everything), so forcing a pipe here would affect a lot of
stuff.
And adding a filter here seems trivial, so I've done that now. If
somebody knows a switch to twiddle instead, we can revisit this.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-10-01 14:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-30 18:21 bug#58199: 29.0.50; Odd "git pull" output Lars Ingebrigtsen
2022-09-30 18:40 ` Eli Zaretskii
2022-10-01 13:37 ` Lars Ingebrigtsen
2022-10-01 13:41 ` Lars Ingebrigtsen
2022-10-01 13:52 ` Eli Zaretskii
2022-10-01 14:08 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).