Peter Kjellerstedt <peter.kjellerstedt@xxxxxxxx> wrote:
> >
> > 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html