Re: Git sideband hook output

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jun 10, 2010, 18:30 UTC
Message-ID: <20100610183019.GR14847@spearce.org>
In-Reply-To: <A612847CFE53224C91B23E3A5B48BAC744839BF6AE@xmail3.se.axis.com>

Peter Kjellerstedt <peter.kjellerstedt@axis.com> wrote:

Show 9 quoted lines

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

Show 6 quoted lines

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

Show 5 quoted lines

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