Johannes Schindelin writes:
> Hi,
>
> is there a special reason you un-Cc:ed the list?
No, my mistake. CCing the mailing list now. I was foiled into
thinking that the reply operation in my email client meant reply-all,
but instead it was set to reply-to-sender-only. Now fixed.
>
> On Tue, 20 Jan 2009, Brent Goodrick wrote:
>
> > Johannes Schindelin writes:
> >
> > > On Tue, 20 Jan 2009, Brent Goodrick wrote:
> > >
> > > > I am considering converting from CVS over to using git. I'm
> > > > currently using git version 1.5.6.5 on Debian Linux "testing".
> > >
> > > First of all, 1.5.6.5 is from last August, so chances are that the
> > > behavior you complain about was fixed in the meantime. We're at
> > > 1.6.1 at the moment.
> >
> > Yes, I thought that was a good point, so I rebuilt from the source
> > tarball git version 1.6.1 and retried my script and got the same
> > behavior.
> >
> > > The only place I can think about where a CR is output is when showing
> > > the progress of downloading.
> > >
> > > Usually, our code checks if stdout is a tty, and does not show
> > > progress.
> > >
> > > As a work-around, piping into cat should work, though.
> >
> > Actually only redirecting stderr and then piping to cat seems to work,
> > e.g.,:
> >
> > get pull 2>&1 | cat
> >
> >
> > I don't mind seeing the progress lines, I just don't want git to emit
> > any CR codes at all.
> >
> > How about a config option to just turn off any tty-detecting logic
> > entirely, so that I don't have to wrap git with a lot of silly scripts
> > that set environment variables and redirect stdout and stderr and piped
> > into "cat"?
>
> Nope, the config option is not needed. This is just a Plain Old Bug which
> needs fixing, that's all.
>
> Let's see what I can do today.
Thanks. The fix should be to arrange it so that I can set something
so that a bare call such as (but just "git pull"):
git pull
will emit no CR codes at all, ever, regardless of if there is a tty.
Even if it is an env var, but a config setting would be ok too.
Thanks,
Brent
Hi,
On Wed, 21 Jan 2009, Brent Goodrick wrote:
Johannes Schindelin writes:
> On Tue, 20 Jan 2009, Brent Goodrick wrote:
>
> > Johannes Schindelin writes:
> >
> > > On Tue, 20 Jan 2009, Brent Goodrick wrote:
> > >
> > > > I am considering converting from CVS over to using git. I'm
> > > > currently using git version 1.5.6.5 on Debian Linux "testing".
> > >
> > > First of all, 1.5.6.5 is from last August, so chances are that
> > > the behavior you complain about was fixed in the meantime.
> > > We're at 1.6.1 at the moment.
> >
> > Yes, I thought that was a good point, so I rebuilt from the source
> > tarball git version 1.6.1 and retried my script and got the same
> > behavior.
> >
> > > The only place I can think about where a CR is output is when
> > > showing the progress of downloading.
> > >
> > > Usually, our code checks if stdout is a tty, and does not show
> > > progress.
> > >
> > > As a work-around, piping into cat should work, though.
> >
> > Actually only redirecting stderr and then piping to cat seems to work,
> > e.g.,:
> >
> > get pull 2>&1 | cat
In my test I performed one minute ago, "git pull | cat" did not show any
CR. Maybe it is the "git" instead of "get" :-)
> > I don't mind seeing the progress lines, I just don't want git to
> > emit any CR codes at all.
> >
> > How about a config option to just turn off any tty-detecting logic
> > entirely, so that I don't have to wrap git with a lot of silly
> > scripts that set environment variables and redirect stdout and
> > stderr and piped into "cat"?
>
> Nope, the config option is not needed. This is just a Plain Old Bug
> which needs fixing, that's all.
>
> Let's see what I can do today.
Thanks. The fix should be to arrange it so that I can set something so
that a bare call such as (but just "git pull"):
git pull
will emit no CR codes at all, ever, regardless of if there is a tty.
Even if it is an env var, but a config setting would be ok too.
I would actually think that it should not be an env var or config setting
if piping it to "cat" does what you want: if the output is a tty, I think
it is safe to assume that you want to see the progress, and if you don't,
"| cat" is not an unreasonable thing to ask for.
Ciao,
Dscho
On Wed, Jan 21, 2009 at 7:38 AM, Johannes Schindelin
In my test I performed one minute ago, "git pull | cat" did not show any
CR. Maybe it is the "git" instead of "get" :-)
<snip>
quoted
Thanks. The fix should be to arrange it so that I can set something so
that a bare call such as (but just "git pull"):
git pull
will emit no CR codes at all, ever, regardless of if there is a tty.
Even if it is an env var, but a config setting would be ok too.
I would actually think that it should not be an env var or config setting
if piping it to "cat" does what you want: if the output is a tty, I think
it is safe to assume that you want to see the progress, and if you don't,
"| cat" is not an unreasonable thing to ask for.
You might not be able to see those CR codes from your terminal,
because ... well ... its a terminal which will process them. And if
you can't reproduce it in your environment, you'll have to duplicate
my environment, and at that is well beyond what I would ask anyone to
do. Thanks for your effort in looking into it. If I get annoyed
enough with it, I'll debug the code myself and propose a patch (but
don't hold your breath because I'm still learning this complex tool).
Thanks!
Brent