Git sideband hook output

Prior to 6d525d where Shawn made the receive-pack process send hook
output over side band #2, how did the hook output get sent to the
client?  On older clients (before this commit) and on older servers,
the hook output just shows up without the 'remote:' prefix.  After
this commit I get the 'remote:' prefix, which is kind of annoying.  Is
there a way to suppress this to get the old output format?  Or a
recommended way of patching the client/server in future versions to
get the old format back?

Thanks,
Scott

Scott Chacon [off-list ref] wrote:

Prior to 6d525d where Shawn made the receive-pack process send hook
output over side band #2, how did the hook output get sent to the
client?

It was sent over stderr, which was proxied down to the client by
the SSH daemon.

On older clients (before this commit) and on older servers,
the hook output just shows up without the 'remote:' prefix.

Because its echoed to the tty by the SSH client, without Git ever
seeing it.

After
this commit I get the 'remote:' prefix,

Now its being parsed out of the stream by the git client, using
the same code that displays the progress messages during clone/fetch.

which is kind of annoying.

Depends on your perspective.  Its nice to know that the messages
came from the server, rather than from your client.  :-)

Is
there a way to suppress this to get the old output format?

No.  Other than to have the hook not output anything at all.

-- 
Shawn.

Am 6/8/2010 22:32, schrieb Scott Chacon:

Prior to 6d525d where Shawn made the receive-pack process send hook
output over side band #2, how did the hook output get sent to the
client?  On older clients (before this commit) and on older servers,
the hook output just shows up without the 'remote:' prefix.  After
this commit I get the 'remote:' prefix, which is kind of annoying.  Is
there a way to suppress this to get the old output format?  Or a
recommended way of patching the client/server in future versions to
get the old format back?

What happens if your git-receive-pack does not announce side-band-64k?

-- Hannes

-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Shawn O. Pearce
Sent: den 8 juni 2010 23:47
To: Scott Chacon
Cc: git list
Subject: Re: Git sideband hook output

Scott Chacon [off-list ref] wrote:

quoted

Prior to 6d525d where Shawn made the receive-pack process send hook
output over side band #2, how did the hook output get sent to the
client?

It was sent over stderr, which was proxied down to the client by
the SSH daemon.

quoted

On older clients (before this commit) and on older servers,
the hook output just shows up without the 'remote:' prefix.

Because its echoed to the tty by the SSH client, without Git ever
seeing it.

quoted

After
this commit I get the 'remote:' prefix,

This explains the messy output from hooks I have seen since 
updating to 1.7.1...

Now its being parsed out of the stream by the git client, using
the same code that displays the progress messages during clone/fetch.

quoted

which is kind of annoying.

Depends on your perspective.  Its nice to know that the messages
came from the server, rather than from your client.  :-)

And it is very annoying that the output format has suddenly changed
so that the output from hooks that rely on the previous no-prefix
format no longer fit on an 80 char wide terminal where they used to
fit just fine.

quoted

Is
there a way to suppress this to get the old output format?

No.  Other than to have the hook not output anything at all.

--
Shawn.

Here is +1 for giving us back the no-prefix output. I would like
to suggest adding a configuration option to allow users to enable 
the "remote: " prefix if they want it.

//Peter

On Wed, 9 Jun 2010, Peter Kjellerstedt wrote:

quoted

-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Shawn O. Pearce
Sent: den 8 juni 2010 23:47
To: Scott Chacon
Cc: git list
Subject: Re: Git sideband hook output

Scott Chacon [off-list ref] wrote:

quoted

Prior to 6d525d where Shawn made the receive-pack process send hook
output over side band #2, how did the hook output get sent to the
client?

It was sent over stderr, which was proxied down to the client by
the SSH daemon.

quoted

On older clients (before this commit) and on older servers,
the hook output just shows up without the 'remote:' prefix.

Because its echoed to the tty by the SSH client, without Git ever
seeing it.

quoted

After
this commit I get the 'remote:' prefix,

This explains the messy output from hooks I have seen since 
updating to 1.7.1...

quoted

Now its being parsed out of the stream by the git client, using
the same code that displays the progress messages during clone/fetch.

quoted

which is kind of annoying.

Depends on your perspective.  Its nice to know that the messages
came from the server, rather than from your client.  :-)

And it is very annoying that the output format has suddenly changed
so that the output from hooks that rely on the previous no-prefix
format no longer fit on an 80 char wide terminal where they used to
fit just fine.

Fix your hook output then.

quoted

quoted

Is
there a way to suppress this to get the old output format?

No.  Other than to have the hook not output anything at all.

--
Shawn.

Here is +1 for giving us back the no-prefix output. I would like
to suggest adding a configuration option to allow users to enable 
the "remote: " prefix if they want it.

Would be much more logical to fix the hook output, and keep hook 
developers honnest by not confusing the user with output that isn't 
local stuff.

-1


Nicolas

-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Nicolas Pitre
Sent: den 9 juni 2010 15:44
To: Peter Kjellerstedt
Cc: Shawn O. Pearce; Scott Chacon; git list
Subject: RE: Git sideband hook output

On Wed, 9 Jun 2010, Peter Kjellerstedt wrote:

quoted

quoted

-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org]
On Behalf Of Shawn O. Pearce
Sent: den 8 juni 2010 23:47
To: Scott Chacon
Cc: git list
Subject: Re: Git sideband hook output

Scott Chacon [off-list ref] wrote:

quoted

Prior to 6d525d where Shawn made the receive-pack process send
hook output over side band #2, how did the hook output get 
sent to the client?

It was sent over stderr, which was proxied down to the client by
the SSH daemon.

quoted

On older clients (before this commit) and on older servers,
the hook output just shows up without the 'remote:' prefix.

Because its echoed to the tty by the SSH client, without Git ever
seeing it.

quoted

After
this commit I get the 'remote:' prefix,

This explains the messy output from hooks I have seen since
updating to 1.7.1...

quoted

Now its being parsed out of the stream by the git client, using
the same code that displays the progress messages during
clone/fetch.

quoted

which is kind of annoying.

Depends on your perspective.  Its nice to know that the messages
came from the server, rather than from your client.  :-)

And it is very annoying that the output format has suddenly changed
so that the output from hooks that rely on the previous no-prefix
format no longer fit on an 80 char wide terminal where they used to
fit just fine.

Fix your hook output then.

I can do that for our hooks, but all may not have that option.

quoted

quoted

quoted

Is
there a way to suppress this to get the old output format?

No.  Other than to have the hook not output anything at all.

--
Shawn.

Here is +1 for giving us back the no-prefix output. I would like
to suggest adding a configuration option to allow users to enable
the "remote: " prefix if they want it.

Would be much more logical to fix the hook output, and keep hook
developers honnest by not confusing the user with output that isn't
local stuff.

Why should the user care whether the output is generated locally 
or remotely? Shouldn't you prefix local hook output then as well
to separate it from the output of the git commands themselves 
(and no, I am not suggesting this is added)?

-1


Nicolas

As I see it this change has taken away a little bit of freedom.
Previously I (as a hook writer) could choose to add a prefix like 
"remote:" to my hook if I wanted to, to make it more obvious that the
output came from the remote server, _or_ I could choose not to and 
have a standardized output that looked the same regardless of whether
it was a local hook or a remote one that complained about the 
formatting of a commit message. Now I no longer have that option.

And what if my hook output is localized? Now there is an English
"remote:" in front of every line... Or even worse, what if the
"remote:" string is localized in a future version of git, then I 
have no way of knowing how wide it is and cannot take measures to 
format my hook output so that it will look right.

//Peter

On Thu, 10 Jun 2010, Peter Kjellerstedt wrote:

Behalf Of Nicolas Pitre

quoted

On Wed, 9 Jun 2010, Peter Kjellerstedt wrote:

quoted

And it is very annoying that the output format has suddenly changed
so that the output from hooks that rely on the previous no-prefix
format no longer fit on an 80 char wide terminal where they used to
fit just fine.

Fix your hook output then.

I can do that for our hooks, but all may not have that option.

Why not?  If that's a real impossibility then people can enlarge their 
terminal window.  No one mandated that the git commands have to be run 
in a 80x25 terminal to work anyway.

quoted

quoted

quoted

quoted

Is
there a way to suppress this to get the old output format?

No.  Other than to have the hook not output anything at all.

--
Shawn.

Here is +1 for giving us back the no-prefix output. I would like
to suggest adding a configuration option to allow users to enable
the "remote: " prefix if they want it.

Would be much more logical to fix the hook output, and keep hook
developers honnest by not confusing the user with output that isn't
local stuff.

Why should the user care whether the output is generated locally 
or remotely?

Think about things like "out of disk space", or "access permission 
denied", or "repository corrupted", etc.  You really want to know if 
those are local or remote.

Shouldn't you prefix local hook output then as well
to separate it from the output of the git commands themselves 
(and no, I am not suggesting this is added)?

I don't see this being as relevant.  It is way far more confusing if a 
remote message can be confused with a local one.

As I see it this change has taken away a little bit of freedom.
Previously I (as a hook writer) could choose to add a prefix like 
"remote:" to my hook if I wanted to, to make it more obvious that the
output came from the remote server, _or_ I could choose not to and 
have a standardized output that looked the same regardless of whether
it was a local hook or a remote one that complained about the 
formatting of a commit message. Now I no longer have that option.

Previously you even didn't have the option of generating messages to be 
displayed on the client's console at all.  If that happened to work with 
SSH that was by pure accident, and causing lots of confusion as remote 
errors were displayed like local ones.  If you tried to push using the 
native Git transport, or the smart HTTP transport, then you would have 
got nothing at all as the hook output was simply dropped on the floor.  
Now this has been fixed, and remote messages are formalized with a 
"remote:" prefix.

And what if my hook output is localized? Now there is an English
"remote:" in front of every line... Or even worse, what if the
"remote:" string is localized in a future version of git, then I 
have no way of knowing how wide it is and cannot take measures to 
format my hook output so that it will look right.

Just don't assume anything about the remote terminal size, because you 
actually don't know what the remote terminal size is.  If you *really* 
need to know that information, then the best solution is to create a 
protocol capability for that with the screen width encoded in it, minus 
the "remote" prefix of course.


Nicolas

Peter Kjellerstedt [off-list ref] wrote:

quoted

Would be much more logical to fix the hook output, and keep hook
developers honnest by not confusing the user with output that isn't
local stuff.

Why should the user care whether the output is generated locally 
or remotely? Shouldn't you prefix local hook output then as well
to separate it from the output of the git commands themselves 
(and no, I am not suggesting this is added)?

Because, I've been confused by hook output before.  A lot of users
have been.  We've also been confused by terminal captures posted
by users when they are having trouble with Git, it does help to
debug the problem by knowing what came from the remote side, and
what was reported locally.

The use of 'remote:' as a prefix dates back to August 2006,
in commit 2de196fe by Junio Hamano.  Prior to that we used
VT100 coloring, which Junio Hamano added that same month in
commit dfa46478:

    fetch/clone: mark messages from remote side stand out.
    
    When dealing with a corrupt or out of sync remote repository,
    the user often gets error messages like this:
    
        error: refs/heads/devel does not point to a valid commit object!
    
    which leaves the user wondering if the breakage is on the local
    end or on the remote end.  This is unnecessarily alarming.
    
    This patch changes the way we display messages received from the
    remote side over the git protocol sideband (i.e. stderr stream
    of the remote process).  It shows them with blue background with
    white letters, but this presentation is subject to proposals of
    better ways from the list.
    
    The problem was pointed out by Andrew Morton.

I guess its a long standing history now that messages from the
remote side should get echoed with 'remote:' to better describe
what is going on.

As for why it got picked up by remote hooks, its because I reused
the code, because I reused the network protocol.

As I see it this change has taken away a little bit of freedom.

But its made the whole thing more honest.

Messages from the remote are now clearly marked as "this is stuff
the other side is trying to tell you", which is different from the
status update we display later showing the outcome of the push.

Previously I (as a hook writer) could choose to add a prefix like 
"remote:" to my hook if I wanted to, to make it more obvious that the
output came from the remote server, _or_ I could choose not to and 
have a standardized output that looked the same regardless of whether
it was a local hook or a remote one that complained about the 
formatting of a commit message. Now I no longer have that option.

But as a user, I really want to know what was hook output, and what
was output from Git.  Putting "remote: " in front helps me to see
the difference.

And what if my hook output is localized? Now there is an English
"remote:" in front of every line... Or even worse, what if the
"remote:" string is localized in a future version of git, then I 
have no way of knowing how wide it is and cannot take measures to 
format my hook output so that it will look right.

Don't localize "remote:"?  Or pick a shorter translation?

If its really a problem, maybe "remote: " prefix should turn into
something shorter and language agnostic, like "<< ".  But thus far
we hadn't had to worry about it, since we didn't have translation
support in Git...  (though yes, I see that is changing now).

-- 
Shawn.

Hey,

On Thu, Jun 10, 2010 at 8:30 PM, Shawn O. Pearce [off-list ref] wrote:

If its really a problem, maybe "remote: " prefix should turn into
something shorter and language agnostic, like "<< ".  But thus far
we hadn't had to worry about it, since we didn't have translation
support in Git...  (though yes, I see that is changing now).

I would heavily be in favor of a change to '>>' or '<<'.  A lot of
services use the hook output to add useful info after or during a push
and the 'remote:' string is distracting for the user.  +1 to '>>'.  Or
perhaps be configurable, but default to '>>'.

Scott

Hi,

On Thu, Jun 10, 2010 at 8:30 PM, Shawn O. Pearce [off-list ref] wrote:

quoted

If its really a problem, maybe "remote: " prefix should turn into
something shorter and language agnostic, like "<< ".  But thus far
we hadn't had to worry about it, since we didn't have translation
support in Git...  (though yes, I see that is changing now).

I'm also in favor of making the default '>>' instead of 'remote:' if
nothing isn't an option.

Using Heroku as an example, this is what their current hook output looks like:

$ git push origin master
Counting objects: 9, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 684 bytes, done.
Total 5 (delta 2), reused 0 (delta 0)

-----> Heroku receiving push
-----> Sinatra app detected
       Compiled slug size is 3.9MB
-----> Launching....... done
       http://fi-quote.heroku.com deployed to Heroku

To git@heroku.com:fi-quote.git
   0bb7fa2..2755742  master -> master


Now, if you compare that to what it would look like if they were
running a more recent version of git, the verboseness of remote: is
quite apparent:


$ git push origin master
Counting objects: 9, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 684 bytes, done.
Total 5 (delta 2), reused 0 (delta 0)
remote:
remote: -----> Heroku receiving push
remote: -----> Sinatra app detected
remote:       Compiled slug size is 3.9MB
remote: -----> Launching....... done
remote:       http://fi-quote.heroku.com deployed to Heroku
remote:
To git@heroku.com:fi-quote.git
   0bb7fa2..2755742  master -> master

In a perfect world, I think it should be up to the user to determine
the amount of information they receive (using a verbose switch
perhaps), but short of that, at least toning down what is output would
be much appreciated.

Cheers,
PJ

El 11/06/2010, a las 16:34, PJ Hyett escribió:

Hi,

quoted

On Thu, Jun 10, 2010 at 8:30 PM, Shawn O. Pearce [off-list ref] wrote:

quoted

If its really a problem, maybe "remote: " prefix should turn into
something shorter and language agnostic, like "<< ".  But thus far
we hadn't had to worry about it, since we didn't have translation
support in Git...  (though yes, I see that is changing now).

I'm also in favor of making the default '>>' instead of 'remote:' if
nothing isn't an option.

Funny, as '>>' is basically meaningless. At least 'remote:' has semantic value (ie. it indicates _where_ something is coming from).

Wincent

On Fri, Jun 11, 2010 at 4:45 PM, Wincent Colaiuta [off-list ref] wrote:

El 11/06/2010, a las 16:34, PJ Hyett escribió:

quoted

Hi,

quoted

On Thu, Jun 10, 2010 at 8:30 PM, Shawn O. Pearce [off-list ref] wrote:

quoted

If its really a problem, maybe "remote: " prefix should turn into
something shorter and language agnostic, like "<< ".  But thus far
we hadn't had to worry about it, since we didn't have translation
support in Git...  (though yes, I see that is changing now).

I'm also in favor of making the default '>>' instead of 'remote:' if
nothing isn't an option.

Funny, as '>>' is basically meaningless. At least 'remote:' has semantic value (ie. it indicates _where_ something is coming from).

How about '> ', which often means "quote" (e.g in e-mails)? Would that
be appropriate?

-- 
Erik "kusma" Faye-Lund

On Thu, Jun 10, 2010 at 18:30, Shawn O. Pearce [off-list ref] wrote:

Peter Kjellerstedt [off-list ref] wrote:

quoted

And what if my hook output is localized? Now there is an English
"remote:" in front of every line... Or even worse, what if the
"remote:" string is localized in a future version of git, then I
have no way of knowing how wide it is and cannot take measures to
format my hook output so that it will look right.

Don't localize "remote:"?  Or pick a shorter translation?

If its really a problem, maybe "remote: " prefix should turn into
something shorter and language agnostic, like "<< ".  But thus far
we hadn't had to worry about it, since we didn't have translation
support in Git...  (though yes, I see that is changing now).

Is there any reason for why the "remote:" output needs to be echoed
verbatim to the user instead of being passed through some filter.

If not, then it could be treated as part of a protocol, parsed, and
localized however the user wants.

">" isn't as language-agnostic as you might think, in a RTL language
the arrow ends up facing the wrong way.

Wincent Colaiuta wrote:

El 11/06/2010, a las 16:34, PJ Hyett escribió:

quoted

Hi,

quoted

On Thu, Jun 10, 2010 at 8:30 PM, Shawn O. Pearce [off-list ref] wrote:

quoted

If its really a problem, maybe "remote: " prefix should turn into
something shorter and language agnostic, like "<< ".  But thus far
we hadn't had to worry about it, since we didn't have translation
support in Git...  (though yes, I see that is changing now).

I'm also in favor of making the default '>>' instead of 'remote:' if
nothing isn't an option.

Funny, as '>>' is basically meaningless. At least 'remote:' has semantic value (ie. it indicates _where_ something is coming from).

Seconded.

Ævar Arnfjörð Bjarmason wrote:

On Thu, Jun 10, 2010 at 18:30, Shawn O. Pearce [off-list ref] wrote:

quoted

Peter Kjellerstedt [off-list ref] wrote:

quoted

And what if my hook output is localized? Now there is an English
"remote:" in front of every line... Or even worse, what if the
"remote:" string is localized in a future version of git, then I
have no way of knowing how wide it is and cannot take measures to
format my hook output so that it will look right.

Don't localize "remote:"?  Or pick a shorter translation?

If its really a problem, maybe "remote: " prefix should turn into
something shorter and language agnostic, like "<< ".  But thus far
we hadn't had to worry about it, since we didn't have translation
support in Git...  (though yes, I see that is changing now).

Is there any reason for why the "remote:" output needs to be echoed
verbatim to the user instead of being passed through some filter.

If not, then it could be treated as part of a protocol, parsed, and
localized however the user wants.

">" isn't as language-agnostic as you might think, in a RTL language
the arrow ends up facing the wrong way.

Also seconded.

Erik Faye-Lund [off-list ref] writes:

quoted

Funny, as '>>' is basically meaningless. At least 'remote:' has semantic value (ie. it indicates _where_ something is coming from).

How about '> ', which often means "quote" (e.g in e-mails)? Would that
be appropriate?

Not much better, IMNSHO.  Where do people get the idea that line-noises
are more descriptive than "remote:"?

On Fri, Jun 11, 2010 at 04:52:46PM -0700, Junio C Hamano wrote:

Erik Faye-Lund [off-list ref] writes:

quoted

quoted

Funny, as '>>' is basically meaningless. At least 'remote:' has semantic value (ie. it indicates _where_ something is coming from).

How about '> ', which often means "quote" (e.g in e-mails)? Would that
be appropriate?

Not much better, IMNSHO.  Where do people get the idea that line-noises
are more descriptive than "remote:"?

I also find '>' ugly, but maybe it is worth quelling the bikeshed
discussion with something like the following.

diff --git a/cache.h b/cache.h
index 5e55367..c616513 100644
--- a/cache.h
+++ b/cache.h

@@ -999,6 +999,7 @@ extern int pager_use_color;
 
 extern const char *editor_program;
 extern const char *excludes_file;
+extern const char *sideband_prefix;
 
 /* base85 */
 int decode_85(char *dst, const char *line, int linelen);

diff --git a/config.c b/config.c
index 9b6b1df..22a1b04 100644
--- a/config.c
+++ b/config.c

@@ -579,6 +579,9 @@ static int git_default_core_config(const char *var, const char *value)
 		return 0;
 	}
 
+	if (!strcmp(var, "core.sidebandprefix"))
+		return git_config_string(&sideband_prefix, var, value);
+
 	/* Add other config variables here and to Documentation/config.txt. */
 	return 0;
 }

diff --git a/sideband.c b/sideband.c
index d5ffa1c..be4a785 100644
--- a/sideband.c
+++ b/sideband.c

@@ -12,22 +12,27 @@
  * the remote died unexpectedly.  A flush() concludes the stream.
  */
 
-#define PREFIX "remote:"
+#define DEFAULT_PREFIX "remote:"
 
 #define ANSI_SUFFIX "\033[K"
 #define DUMB_SUFFIX "        "
 
 #define FIX_SIZE 10  /* large enough for any of the above */
 
+char *sideband_prefix = DEFAULT_PREFIX;
+
 int recv_sideband(const char *me, int in_stream, int out)
 {
-	unsigned pf = strlen(PREFIX);
+	unsigned pf = strlen(sideband_prefix);
 	unsigned sf;
 	char buf[LARGE_PACKET_MAX + 2*FIX_SIZE];
 	char *suffix, *term;
 	int skip_pf = 0;
 
-	memcpy(buf, PREFIX, pf);
+	if (pf > FIX_SIZE)
+		pf = FIX_SIZE;
+
+	memcpy(buf, sideband_prefix, pf);
 	term = getenv("TERM");
 	if (term && strcmp(term, "dumb"))
 		suffix = ANSI_SUFFIX;