Git reports

Git reports

[Muzaffer Tolga Ozses]

Hi,

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?

Regards,
mto

Re: Git reports

[Konstantin Khomoutov]

On Fri, 6 Dec 2013 18:51:47 +0200
Muzaffer Tolga Ozses <tolga@ozses.net> wrote:

> 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?

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).
Or you pass the "-q" command-line option to `git clone`.

Re: Git reports

[Konstantin Khomoutov]

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?

Re: Git reports

[Muzaffer Tolga Ozses]

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 6 December 2013 19:09, Konstantin Khomoutov
<flatworm@users.sourceforge.net> wrote:
> 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?

Re: Git reports

[Jeff King]

On Fri, Dec 06, 2013 at 07:44:21PM +0200, Muzaffer Tolga Ozses wrote:

> 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.

What protocol/transport are you using (http, ssh, git)?

Can you try running with:

  GIT_TRACE_PACKET=$PWD/trace.out git clone ...

You should be able to see whether the client tells the server to
suppress progress output (look for the first "want" line in the output,
which may or may not contain the flag "no-progress"). That will let us
figure out whether it is the client who is unexpectedly asking to turn
off progress, or whether the server is failing to produce progress.

-Peff

Re: Git reports

[Konstantin Khomoutov]

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?

Re: Git reports

[Muzaffer Tolga Ozses]

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?

Re: Git reports

[Muzaffer Tolga Ozses]

Sorry, my git server is on CentOS and git 1.8.4.2 and my machine on
which I clone is Ubuntu, 1.8.3.2

On 6 December 2013 21:19, Muzaffer Tolga Ozses <tolga@ozses.net> wrote:
> 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?

Re: Git reports

[Jonathan Nieder]

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. ;-)

Thanks and hope that helps,
Jonathan

Re: Git reports

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> 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 wouldn't be worried too much about progress display, but I would
think it might be a good idea to teach the http client side, perhaps
with a -v option, to report which variant of the protocol is in use,
primarily to warn those who have a server that is capable of running
the smart protocol but forgot to set it up, or unaware that smart is
generally a better option for them.

Re: Git reports

[Jeff King]

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

Re: Git reports

[Muzaffer Tolga Ozses]

I looked at man git-http-backend, and I didn't understand a thing.
I'll look at it tomorrow again with a clear head.

On 7 December 2013 00:22, Jeff King <peff@peff.net> wrote:
> 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