Re: Meaning of "fatal: protocol error: bad line length character"?
- From
Junio C Hamano <junkio@cox.net>
- Date
- Jan 22, 2007, 20:15 UTC
- Message-ID
- <7vr6tmstri.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <20070120213738.GA8973@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 14 quoted lines
> Junio C Hamano <junkio@cox.net> wrote: >> Funny thing is, at least in recent enough git, I think we set up >> redirection to force output from hook scripts to stderr, but I >> do not remember when it happened. Let's see... >> >> ...goes and looks... >> >> That was supposed to have been fixed with commit cd83c74c (Dec >> 30, 2006), but this indicates the fix is not working at all when >> your login shell is tcsh. > > Don't tell us tcsh is doing something ugly like opening the tty for > stdout/stderr instead of using the ones it inherited from its parent. > 'cause that's just useless!
It turns out that this was a stupidity on the part of the tester (i.e. me).
I let the distro to install a version of git in /usr/bin/, and my .cshrc is not set up to add /home/junio/git-active/bin (I have $HOME/git-{master,next,pu,maint}/bin and git-active is a symlink to git-master right now -- usually it points at git-next), for non-interactive session like invoking receive-pack. But my bash startup does. The breakage I was seeing was _NOT_ because of differences between tcsh and bash, but because the fix is fairly recent.
I forced the master version of receive-pack to be used on the remote side using --receive-pack command line parameter, and things seem to work fine with either tcsh or bash.
So, no, there might be valid reasons to hate tcsh, but this is not one of them.