Git reports

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

On Fri, 6 Dec 2013 18:51:47 +0200
Muzaffer Tolga Ozses [off-list ref] 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`.

On Fri, 6 Dec 2013 21:00:35 +0400
Konstantin Khomoutov [off-list ref] wrote:

[...]

quoted

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.

On 6 December 2013 19:09, Konstantin Khomoutov
[off-list ref] wrote:

On Fri, 6 Dec 2013 21:00:35 +0400
Konstantin Khomoutov [off-list ref] wrote:

[...]

quoted

quoted

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?

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

On Fri, 6 Dec 2013 19:44:21 +0200
Muzaffer Tolga Ozses [off-list ref] wrote:

[...]

quoted

quoted

quoted

Resolving deltas: 100% (369/369), done.

whereas I don't get those with my own. What could I be doing
wrong?

[...]

quoted

quoted

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

[...]

quoted

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
[off-list ref] wrote:

On Fri, 6 Dec 2013 19:44:21 +0200
Muzaffer Tolga Ozses [off-list ref] wrote:

[...]

quoted

quoted

quoted

quoted

Resolving deltas: 100% (369/369), done.

whereas I don't get those with my own. What could I be doing
wrong?

[...]

quoted

quoted

quoted

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

[...]

quoted

quoted

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?

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 [off-list ref] wrote:

Hi,

quoted

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

I am cloning over http

quoted

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.

quoted

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.

quoted

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

quoted

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
[off-list ref] wrote:

quoted

On Fri, 6 Dec 2013 19:44:21 +0200
Muzaffer Tolga Ozses [off-list ref] wrote:

[...]

quoted

quoted

quoted

quoted

Resolving deltas: 100% (369/369), done.

whereas I don't get those with my own. What could I be doing
wrong?

[...]

quoted

quoted

quoted

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

[...]

quoted

quoted

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

Thanks and hope that helps,
Jonathan

On Fri, Dec 06, 2013 at 11:26:51AM -0800, Jonathan Nieder wrote:

quoted

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

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 [off-list ref] wrote:

On Fri, Dec 06, 2013 at 11:26:51AM -0800, Jonathan Nieder wrote:

quoted

quoted

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.

quoted

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