Buffered value should be shown when requesting username for remote authentication

Buffered value should be shown when requesting username for remote authentication

[Kaartic Sivaraam]

Hello all,

I noted a little issue with the interaction to a remote git repository.
The issue occurs when the network used for remote communication is a
bit sluggish. The main issue is illustrated by the following shell
interaction,

    $ git push -u fork 
    sivaraamUsername for '    https://github.com'    : sivaraam
    Password for '    https://sivaraamsivaraam@github.com':     

    It's a little odd that the (buffered) input found before the request
    for 'Username' is also appended to the input found after the request.
    This might not be obvious to the user and he has to retype the
    'Username' in the next try.

    I have seen some utilities handle this correctly by doing something
    like,

    $ <some-utility> 
    sivaUsername for '    https://github.com'    : siva

        Further, unlike the request string, the buffered input that gets
        printed after the request was editable. I'm not able to recollect the
        <some-utility> correctly, though.

        Any ideas about how to fix this?

        -- 
        Kaartic

Re: Buffered value should be shown when requesting username for remote authentication

[Jeff King]

On Tue, Sep 12, 2017 at 06:17:29PM +0530, Kaartic Sivaraam wrote:

> I noted a little issue with the interaction to a remote git repository.
> The issue occurs when the network used for remote communication is a
> bit sluggish. The main issue is illustrated by the following shell
> interaction,
> 
>     $ git push -u fork 
>     sivaraamUsername for '    https://github.com'    : sivaraam
>     Password for '    https://sivaraamsivaraam@github.com':     
> 
>     It's a little odd that the (buffered) input found before the request
>     for 'Username' is also appended to the input found after the request.
>     This might not be obvious to the user and he has to retype the
>     'Username' in the next try.

If I understand right, you typed "sivaraam" once, then the network
lagged, then you typed "sivaraam" again.

That isn't really something that Git can fix reliably. Reading those
characters and echoing them back to the terminal is handled by your
terminal driver (and potentially other things like ssh).  Git may have
received "sivaraamsivaraam" all at once, depending on where the lag is.

-Peff

Re: Buffered value should be shown when requesting username for remote authentication

[Kaartic Sivaraam]

On Tuesday 12 September 2017 09:03 PM, Jeff King wrote:
> If I understand right, you typed "sivaraam" once, then the network
> lagged, then you typed "sivaraam" again.
Almost there but I should have been more clearer. What I actually did was I
run `git push` and knowing it would ask for a username I started typing 
it immediately
without looking at the terminal to notice that the request for the 
username hasn't
shown up yet due to the slow network. the terminal was like this before 
the request showed up,

    $ git push
    sivaraam

After the request showed up the terminal was like,

    $ git push
    sivaraamUsername for 'https://github.com' :

I thought the buffered input wasn't recognised as it didn't show up 
after the request.
So, I typed the username once more to get this,

      $ git push -u fork
      sivaraamUsername for 'https://github.com' : sivaraam
      Password for 'https://sivaraamsivaraam@github.com :

I have been accustomed with this now a days that I don't do the same 
mistake now. I thought
it would nice if this could be fixed as I have seen utilities show the 
buffered input after the
request but as I stated before I'm not able to recollect which utility 
it was (hope I had better
memory)

> That isn't really something that Git can fix reliably. Reading those
> characters and echoing them back to the terminal is handled by your
> terminal driver (and potentially other things like ssh).  Git may have
> received "sivaraamsivaraam" all at once, depending on where the lag is.

I expected this but wasn't sure which "potential thing" was handling the 
'https' handling in the background.
I guess it's 'curl' but not sure.

---
Kaartic