RE: Git sideband hook output

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: git-owner@xxxxxxxxxxxxxxx [mailto:git-owner@xxxxxxxxxxxxxxx] 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:
> 
> > > -----Original Message-----
> > > From: git-owner@xxxxxxxxxxxxxxx [mailto:git-owner@xxxxxxxxxxxxxxx]
> > > 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 <schacon@xxxxxxxxx> 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,
> >
> > 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.
> > >
> > > > 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.

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

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]