RE: Git sideband hook output

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

 



On Thu, 10 Jun 2010, Peter Kjellerstedt wrote:

> Behalf Of Nicolas Pitre
> > On Wed, 9 Jun 2010, Peter Kjellerstedt wrote:
> > 
> > > 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.

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