GNU bug report logs - #58199
29.0.50; Odd "git pull" output

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58199 in the body.
You can then email your comments to 58199 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Odd "git pull" output
Date: Fri, 30 Sep 2022 20:21:20 +0200

[Message part 1 (text/plain, inline)]

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:

[Message part 2 (image/png, inline)]

[Message part 3 (text/plain, inline)]

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'

Message #8 received at 58199 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 58199 <at> debbugs.gnu.org
Subject: Re: bug#58199: 29.0.50; Odd "git pull" output
Date: Fri, 30 Sep 2022 21:40:41 +0300

> From: Lars Ingebrigtsen <larsi <at> 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.

Message #11 received at 58199 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58199 <at> debbugs.gnu.org
Subject: Re: bug#58199: 29.0.50; Odd "git pull" output
Date: Sat, 01 Oct 2022 15:37:03 +0200

Eli Zaretskii <eliz <at> 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.

Message #14 received at 58199 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58199 <at> debbugs.gnu.org
Subject: Re: bug#58199: 29.0.50; Odd "git pull" output
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?

Message #17 received at 58199 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 58199 <at> debbugs.gnu.org
Subject: Re: bug#58199: 29.0.50; Odd "git pull" output
Date: Sat, 01 Oct 2022 16:52:34 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 58199 <at> 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?

Message #20 received at 58199 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58199 <at> debbugs.gnu.org
Subject: Re: bug#58199: 29.0.50; Odd "git pull" output
Date: Sat, 01 Oct 2022 16:08:29 +0200

Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.