git bash-completion is incorrect for "git pull origin mas<tab>" if the ssh key is encrypted
Hello everyone,
If my ssh key is encrypted, "git pull origin mas<tab>" will give a unexpected result, something like this:
git pull origin masEnter passphrase for key '/home/user/.ssh/id_rsa':
I know maybe it is not possible to complete the "master", but maybe it is better to not complete anything than append something like that?
Thanks!
Hong
Quoted 9 lines · Hong Xu
Hello everyone,
If my ssh key is encrypted, "git pull origin mas<tab>" will give a unexpected result, something like this:
git pull origin masEnter passphrase for key '
/home/user/.ssh/id_rsa':I know maybe it is not possible to complete the "master", but maybe it is better to not complete anything than append something like that?
It is ssh itself which emits this message. The completion script calls 'git ls-remote origin', which in turn invokes ssh. Typing the password in actually works, but I understand that you are annoyed by the message.
I don't think there's an easy way to silence this in git completion, without affecting other times when the key would be requested. E.g. we would want ssh to ask for the key while doing 'git pull', but not when run automatically during completion.
Maybe git-ls-remote should learn --quiet?
Zbyszek
Am 3/22/2012 11:28, schrieb Zbigniew Jędrzejewski-Szmek:
Quoted 14 lines · Hong Xu
Quoted 9 lines
Hello everyone,
If my ssh key is encrypted, "git pull origin mas<tab>" will give a unexpected result, something like this:
git pull origin masEnter passphrase for key '
/home/user/.ssh/id_rsa':I know maybe it is not possible to complete the "master", but maybe it is better to not complete anything than append something like that?
It is ssh itself which emits this message. The completion script calls 'git ls-remote origin', which in turn invokes ssh. Typing the password in actually works, but I understand that you are annoyed by the message.
Quoted 6 lines
I don't think there's an easy way to silence this in git completion, without affecting other times when the key would be requested. E.g. we would want ssh to ask for the key while doing 'git pull', but not when run automatically during completion.
Maybe git-ls-remote should learn --quiet?
No. IMHO, bash completion stretches too far by asking the remote for the refs that it has.
-- Hannes
Quoted 20 lines · Johannes Sixt
Am 3/22/2012 11:28, schrieb Zbigniew Jędrzejewski-Szmek:
Quoted 19 lines · Hong Xu
Quoted 9 lines
Hello everyone,
If my ssh key is encrypted, "git pull origin mas<tab>" will give a unexpected result, something like this:
git pull origin masEnter passphrase for key '
/home/user/.ssh/id_rsa':I know maybe it is not possible to complete the "master", but maybe it is better to not complete anything than append something like that?
It is ssh itself which emits this message. The completion script calls 'git ls-remote origin', which in turn invokes ssh. Typing the password in actually works, but I understand that you are annoyed by the message.
I don't think there's an easy way to silence this in git completion, without affecting other times when the key would be requested. E.g. we would want ssh to ask for the key while doing 'git pull', but not when run automatically during completion.
Quoted 5 lines
Quoted 1 line
Maybe git-ls-remote should learn --quiet?
No. IMHO, bash completion stretches too far by asking the remote for the refs that it has.
I agree with this rather than using silent mode. If a encrypted key is found, I think we better drop the completion. I don't know whether there is a way to implement this yet, at least we can try to find it.
Hong
Quoted 24 lines · Hong Xu
Quoted 20 lines · Johannes Sixt
Am 3/22/2012 11:28, schrieb Zbigniew Jędrzejewski-Szmek:
Quoted 19 lines · Hong Xu
Quoted 9 lines
Hello everyone,
If my ssh key is encrypted, "git pull origin mas<tab>" will give a unexpected result, something like this:
git pull origin masEnter passphrase for key '
/home/user/.ssh/id_rsa':I know maybe it is not possible to complete the "master", but maybe it is better to not complete anything than append something like that?
It is ssh itself which emits this message. The completion script calls 'git ls-remote origin', which in turn invokes ssh. Typing the password in actually works, but I understand that you are annoyed by the message.
I don't think there's an easy way to silence this in git completion, without affecting other times when the key would be requested. E.g. we would want ssh to ask for the key while doing 'git pull', but not when run automatically during completion.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Maybe git-ls-remote should learn --quiet?
No. IMHO, bash completion stretches too far by asking the remote for the refs that it has.
I agree with this rather than using silent mode. If a encrypted key is found, I think we better drop the completion. I don't know whether there is a way to implement this yet, at least we can try to find it.
There's more than one reason why ssh would ask for a password. So just
checking for an encrypted key is pointless. Instead, ssh could be invoked with -o BatchMode=yes. ls-remote could pass this option if it was invoked with --quiet.
Possible this is just not worth the trouble and Hong should enter the run ssh-agent and enter the password beforehand.
Zbyszek
Quoted 33 lines · Zbigniew Jędrzejewski-Szmek
Quoted 32 lines · Hong Xu
Quoted 27 lines · Johannes Sixt
Am 3/22/2012 11:28, schrieb Zbigniew Jędrzejewski-Szmek:
Quoted 15 lines · Hong Xu
Quoted 9 lines
Hello everyone,
If my ssh key is encrypted, "git pull origin mas<tab>" will give a unexpected result, something like this:
git pull origin masEnter passphrase for key '
/home/user/.ssh/id_rsa':I know maybe it is not possible to complete the "master", but maybe it is better to not complete anything than append something like that?
It is ssh itself which emits this message. The completion script calls 'git ls-remote origin', which in turn invokes ssh. Typing the password in
actually works, but I understand that you are annoyed by the message.Quoted 7 lines
I don't think there's an easy way to silence this in git completion, without affecting other times when the key would be requested. E.g. we would want ssh to ask for the key while doing 'git pull', but not when run
automatically during completion.Maybe git-ls-remote should learn --quiet?
No. IMHO, bash completion stretches too far by asking the remote for the refs that it has.
Quoted 7 lines
Quoted 3 lines
I agree with this rather than using silent mode. If a encrypted key is found, I think we better drop the completion. I don't know whether there is a way to implement this yet, at least we can try to find it.
There's more than one reason why ssh would ask for a password. So just checking for an encrypted key is pointless. Instead, ssh could be invoked with -o BatchMode=yes. ls-remote could pass this option if it was invoked with --quiet.
This is a good idea.
Quoted 3 lines
Possible this is just not worth the trouble and Hong should enter the run ssh-agent and enter the password beforehand.
If I entered the password, it would be like this:
git pull origin masEnter passphrase for key '/home/user/.ssh/id_rsa':
ter
Then I press Enter, the command runs as it should be. The only problem is that this is a bit annoying.
Hong
Quoted 1 line · Zbigniew Jędrzejewski-Szmek
Maybe git-ls-remote should learn --quiet?
I would rather think that the completion should ask for refs only when dealing with local repositories, without going over network, whether the query involves authentication or not.
When given a repository nickname, do we have a good way for the completion script to tell if it is local or remote? "type -d $it" might be cheap way to do so, or we could even do "test $it = ." to limit it really to the current repository.
Quoted 8 lines · Junio C Hamano
Quoted 1 line · Zbigniew Jędrzejewski-Szmek
Maybe git-ls-remote should learn --quiet?
I would rather think that the completion should ask for refs only when dealing with local repositories, without going over network, whether the query involves authentication or not.
Could you give some reasons about why shouldn't we go through network?
Hong
Quoted 7 lines · Junio C Hamano
Quoted 1 line · Zbigniew Jędrzejewski-Szmek
Maybe git-ls-remote should learn --quiet?
I would rather think that the completion should ask for refs only when dealing with local repositories, without going over network, whether the query involves authentication or not.
It depends on what "network" is. When the network is just a machine on the same Gb-ethernet LAN, completion can still be useful (only if you have password-less authentication of course). I don't use it much with Git, but I find it handy that ZSH completes rsync remote pathes for example.
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Quoted 10 lines · Matthieu Moy
Quoted 7 lines · Junio C Hamano
Quoted 1 line · Zbigniew Jędrzejewski-Szmek
Maybe git-ls-remote should learn --quiet?
I would rather think that the completion should ask for refs only when dealing with local repositories, without going over network, whether the query involves authentication or not.
Quoted 5 lines
It depends on what "network" is. When the network is just a machine on the same Gb-ethernet LAN, completion can still be useful (only if you have password-less authentication of course). I don't use it much with Git, but I find it handy that ZSH completes rsync remote pathes for example.
Yeah, I can second that. Even on a slow network, it can be useful. I use ssh with ControlMaster=yes and completion over a relatively slow network is pretty much instantaneous.
-
Zbyszek
Quoted 9 lines · Matthieu Moy
Quoted 3 lines
I would rather think that the completion should ask for refs only when dealing with local repositories, without going over network, whether the query involves authentication or not.
It depends on what "network" is. When the network is just a machine on the same Gb-ethernet LAN, completion can still be useful (only if you have password-less authentication of course). I don't use it much with Git, but I find it handy that ZSH completes rsync remote pathes for example.
Yeah, I agree it depends on your latency-tolerance (which implies that this begs for an "I am impatient, do not go over network" switch).