> When we use ssh to run the receive-pack over the wire while pushing, > we do not ask for pty, and because the "-e" option to set the escape > character is meaningful only when ssh runs with pty allocated, you > shouldn't have to do this, unless you force pty allocation by > e.g. passing "-t" yourself. Then I wonder why I'm getting a pseudoterminal. Note that I'm using git from git bash on Windows in a walled off corporate environment. The ssh manpage says: > If no pseudo-terminal has been allocated, the session is transparent > and can be used to reliably transfer binary data. On most > systems, setting the escape character to ``none'' will also > make the session transparent even if a tty is used. If we want the ssh to be binary transparent regardless (and I think we do) then that makes my suggestion, `ssh -e none`, still perhaps a good one? On Tue, Jul 6, 2021 at 10:03 PM Aaron Hall <aaronchallmba@xxxxxxxxx> wrote: > > I'll reply on list. > > On Tue, Jul 6, 2021 at 9:58 PM Aaron Hall <aaronchallmba@xxxxxxxxx> wrote: > > > > My context is using git from git bash on Windows in a walled off environment. > > > > On Tue, Jul 6, 2021 at 9:48 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > > > Aaron Hall <aaronchallmba@xxxxxxxxx> writes: > > > > > > > I was trying to push some binary files (PNGs) over ssh and found some > > > > files inexplicably wouldn't successfully push. > > > > > > > > I set, in my .gitconfig file: > > > > > > > > [core] > > > > sshCommand = ssh -e none > > > > > > > > And it works now for all files (that I can tell). > > > > > > > > From a close examination of the output where I noted escape codes > > > > showing up, I believe the problem to be ssh escape codes. > > > > > > > > `\n~.` for example closes the ssh client. > > > > > > > > Therefore I think the default ssh command should be `ssh -e none` > > > > instead of `ssh` for the benefit of users who won't recognize the > > > > problem, unless `git` is expected to make use of ssh escape codes. > > > > > > Curious. > > > > > > When we use ssh to run the receive-pack over the wire while pushing, > > > we do not ask for pty, and because the "-e" option to set the escape > > > character is meaningful only when ssh runs with pty allocated, you > > > shouldn't have to do this, unless you force pty allocation by > > > e.g. passing "-t" yourself.
