Git reports

> On another git server, I get reports like
> Cloning into 'tcmb'...
> remote: Counting objects: 704, done.
> remote: Compressing objects: 100% (574/574), done.
> remote: Total 704 (delta 369), reused 107 (delta 60)
> Receiving objects: 100% (704/704), 129.99 KiB | 23 KiB/s, done.
> Resolving deltas: 100% (369/369), done.
> 
> whereas I don't get those with my own. What could I be doing wrong?

> > Resolving deltas: 100% (369/369), done.
> > 
> > whereas I don't get those with my own. What could I be doing wrong?
> 
> The documentation on `git push` states:
> 
>   --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.
> 
> So it might turn out on your own server Git for some reason fails to
> figure out its standard error stream is connected to a terminal.
> Or, the error stream of your shell process is redirected somewhere
> (and hence inherited by Git).

> On Fri, 6 Dec 2013 21:00:35 +0400
> Konstantin Khomoutov <flatworm@users.sourceforge.net> wrote:
>
> [...]
>> > Resolving deltas: 100% (369/369), done.
>> >
>> > whereas I don't get those with my own. What could I be doing wrong?
>>
>> The documentation on `git push` states:
>>
>>   --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.
>>
>> So it might turn out on your own server Git for some reason fails to
>> figure out its standard error stream is connected to a terminal.
>> Or, the error stream of your shell process is redirected somewhere
>> (and hence inherited by Git).
>
> To underline the fact this is not all too unlikely, you're able to
> completely silence error reports in your shell prompt by executing
>
>   exec 2>/dev/null
>
> (you can regain it back by doing `exec 2>&1`).
>
> So you might face a misbehaving shell logon script for instance.
>
> As to whether Git senses the TTY -- what does running
>
>   stty
>
> tells you?  Does it fail with something like "inappropriate ioctl for
> device" or prints a couple of settings?

> stty tells me
> speed 38400 baud; line = 0;
> eol = M-^?; eol2 = M-^?; swtch = M-^?;
> ixany iutf8
> 
> And I run identical commands on both servers, only URL changes.

> > So you might face a misbehaving shell logon script for instance.
> >
> > As to whether Git senses the TTY -- what does running
> >
> >   stty
> >
> > tells you?  Does it fail with something like "inappropriate ioctl
> > for device" or prints a couple of settings?
> stty tells me
> speed 38400 baud; line = 0;
> eol = M-^?; eol2 = M-^?; swtch = M-^?;
> ixany iutf8
> 
> And I run identical commands on both servers, only URL changes.

> On Fri, 6 Dec 2013 19:44:21 +0200
> Muzaffer Tolga Ozses <tolga@ozses.net> wrote:
>
> [...]
>> >> > Resolving deltas: 100% (369/369), done.
>> >> >
>> >> > whereas I don't get those with my own. What could I be doing
>> >> > wrong?
> [...]
>> >> So it might turn out on your own server Git for some reason fails
>> >> to figure out its standard error stream is connected to a terminal.
>> >> Or, the error stream of your shell process is redirected somewhere
>> >> (and hence inherited by Git).
> [...]
>> > So you might face a misbehaving shell logon script for instance.
>> >
>> > As to whether Git senses the TTY -- what does running
>> >
>> >   stty
>> >
>> > tells you?  Does it fail with something like "inappropriate ioctl
>> > for device" or prints a couple of settings?
>> stty tells me
>> speed 38400 baud; line = 0;
>> eol = M-^?; eol2 = M-^?; swtch = M-^?;
>> ixany iutf8
>>
>> And I run identical commands on both servers, only URL changes.
>
> OK, so we could supposedly rule out the possibility Git does not sense
> it's connected to a terminal.
>
> So let's do the next test: does
>
>     echo test >&2
>
> print "test" on the box where Git does not report progress?
>
> Another one: does Git report progress if you explicitly pass --progress
> to it?
>
> Does it work if you do
>
>     git clone $URL 2>&1
>
> ?
>
> What Git and OS versions are on both machines?

> Hi,
>
>> What protocol/transport are you using (http, ssh, git)?
> I am cloning over http
>
>> Can you try running with:
>
>  GIT_TRACE_PACKET=$PWD/trace.out git clone ...
> GIT_TRACE_PACKET=$PWD/trace.out git clone
> http://git.webciniz.im/project/night_pharmacy.git
> Cloning into 'night_pharmacy'...
> Checking connectivity... done
>
> That's all I get. No trace.out was written.
>
>> So let's do the next test: does
>
>     echo test >&2
>
> print "test" on the box where Git does not report progress?
>
> Yes it does.
>
>> Another one: does Git report progress if you explicitly pass --progress
> to it?
>
> git clone --progress http://git.webciniz.im/project/night_pharmacy.git
> Cloning into 'night_pharmacy'...
> Checking connectivity... done
>
> That's all I get
>
>> Does it work if you do
>
>     git clone $URL 2>&1
>
> git clone http://git.webciniz.im/project/night_pharmacy.git 2>&1
> Cloning into 'night_pharmacy'...
> Checking connectivity... done
>
> That's all I get.
>
> Regards
> mto
>
> On 6 December 2013 19:53, Konstantin Khomoutov
> <flatworm@users.sourceforge.net> wrote:
>> On Fri, 6 Dec 2013 19:44:21 +0200
>> Muzaffer Tolga Ozses <tolga@ozses.net> wrote:
>>
>> [...]
>>> >> > Resolving deltas: 100% (369/369), done.
>>> >> >
>>> >> > whereas I don't get those with my own. What could I be doing
>>> >> > wrong?
>> [...]
>>> >> So it might turn out on your own server Git for some reason fails
>>> >> to figure out its standard error stream is connected to a terminal.
>>> >> Or, the error stream of your shell process is redirected somewhere
>>> >> (and hence inherited by Git).
>> [...]
>>> > So you might face a misbehaving shell logon script for instance.
>>> >
>>> > As to whether Git senses the TTY -- what does running
>>> >
>>> >   stty
>>> >
>>> > tells you?  Does it fail with something like "inappropriate ioctl
>>> > for device" or prints a couple of settings?
>>> stty tells me
>>> speed 38400 baud; line = 0;
>>> eol = M-^?; eol2 = M-^?; swtch = M-^?;
>>> ixany iutf8
>>>
>>> And I run identical commands on both servers, only URL changes.
>>
>> OK, so we could supposedly rule out the possibility Git does not sense
>> it's connected to a terminal.
>>
>> So let's do the next test: does
>>
>>     echo test >&2
>>
>> print "test" on the box where Git does not report progress?
>>
>> Another one: does Git report progress if you explicitly pass --progress
>> to it?
>>
>> Does it work if you do
>>
>>     git clone $URL 2>&1
>>
>> ?
>>
>> What Git and OS versions are on both machines?

> Muzaffer Tolga Ozses wrote:
>
>> I am cloning over http
>
> I am guessing you are using the "dumb" (plain static file transfer)
> HTTP protocol.  With that protocol the server doesn't do anything
> other than shuttle out files, so it doesn't need to do its own
> progress reporting.
>
> Perhaps the client should do some progress reporting based on file
> sizes and amount downloaded so far, but it's hard to get excited
> about given the existence of "smart" (transfer only what is needed)
> HTTP protocol.  See git-http-backend(1) for details.
>
> Perhaps we can document this better?  (If so, where would it have been
> useful to learn about this, and do you have ideas for how it could be
> worded?  I'm thinking it might make sense to put a note on this in a
> new giturls(7) page with content that used to be in the git-clone(1)
> 'GIT URLS' section.)  Or if someone wants to work on a progress
> display, that would be nice, too. ;-)

> > I am cloning over http
> 
> I am guessing you are using the "dumb" (plain static file transfer)
> HTTP protocol.  With that protocol the server doesn't do anything
> other than shuttle out files, so it doesn't need to do its own
> progress reporting.

> On Fri, Dec 06, 2013 at 11:26:51AM -0800, Jonathan Nieder wrote:
>
>> > I am cloning over http
>>
>> I am guessing you are using the "dumb" (plain static file transfer)
>> HTTP protocol.  With that protocol the server doesn't do anything
>> other than shuttle out files, so it doesn't need to do its own
>> progress reporting.
>
> Yeah, that would also explain why GIT_TRACE_PACKET produced no output.
>
>> Perhaps the client should do some progress reporting based on file
>> sizes and amount downloaded so far, but it's hard to get excited
>> about given the existence of "smart" (transfer only what is needed)
>> HTTP protocol.  See git-http-backend(1) for details.
>
> You get some very verbose and nasty progress with "-vv". It would be
> nice to have a regular throughput meter for dumb-http, though. I haven't
> bothered adding one so far because I don't expect many people are using
> http. However, if we start supporting fetching via bundles over http,
> then it will be very nice to have some kind of progress display there
> (since the main use is to get gigantic full clones).
>
> -Peff