On 05/05/2021 01:49, Junio C Hamano wrote: > Philip Oakley <philipoakley@iee.email> writes: > >> I was also thinking that the lack of replies maybe links to the "Pain >> points in Git's patch flow" thread <YHaIBvl6Mf7ztJB3@xxxxxxxxxx> whereby >> it's all about the proposed patch, rather than thoughts about a >> potential patch. >> (Sort of like the philosophy of science [method] that ignores opinion, >> and demands evidence) > Actually, the initial message on this matter from Randall came in > the patch form <011e01d73dd0$ec141530$c43c3f90$@nexbridge.com>, so > if it were truly "it's all about the proposed patch, rather than > thoughts about a potential patch", it would have gained much more > responses. I'd missed the patches (at the time) as my mail client hadn't grouped them together, so that mail looked a bit lonely, hence my reply ;-) I saw a later note by Randall that send-email hadn't worked on his system which gave rise to the patches being 'spread about'. > > Other than I didn't have time, the reason I didn't respond was that > the concept and notation used there were a bit too foreign to me to > decide from where to start asking questions. It wasn't clear what > '$ZSSHX' meant (is it the value of an environment variable whose > name is ZSSHX, or is it literally a name with dollar in it and is > the issue being addressed that it is too cumbersome to quote it > properly in value of the GIT_SSH_COMMAND environment variable?) for > example. And after reading the message you are responding to twice, > I do not quite get what problem we are trying to solve. Especially > since > > No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S > $ZSSH0' and that does not work correctly in the current git code > base. > > in <012601d73ddf$3d0cf660$b726e320$@nexbridge.com> sounded like we > have a fairly clearly demonstratable problem (i.e. the handling of > the command line given via GIT_SSH_COMMAND is somehow broken). The > details of "does not work correctly in the current code base" is not > yet disclosed but it sounded like it would be possible to tease it > out and solve the issue in a more direct way. But yet the solution > presented in the three-patch series looked like it was sidestepping > the entire issue and adding a special case for NonStop without > having to touch GIT_SSH_COMMAND at all (presumably leaving it still > "broken"). I didn't understand all that either. I'd just spotted the other ssh variants being common on Windows.. A classic curse of knowledge (or lack of it) problem. Philip
