Re: What's cooking in git.git (Dec 2011, #02; Mon, 5)

Jeff King [off-list ref] writes:

Also, let's drop the top git_getpass bits from the topic for now (they
will not be part of my rebase). They are a separate topic that can go on
top, but I think there was some question from Erik of whether we should
simply roll our own getpass().

Sounds sensible.

I suspect that there may be a codepath where we could ask both username
and password; instead of making two consecutive calls to getpass() or
git_prompt(), the series may want to give a higher level abstraction, so
that GUI can show a dialog with two input fields (single-line input and
password input) and interact only once with the user. Such an input widget
could _show_ the username, and optionally even let it edited (there may be
ramifications depending on how the codepath uses the username), while
asking for the corresponding password.

quoted

* jk/maint-1.6.2-upload-archive (2011-11-21) 1 commit
 - archive: don't let remote clients get unreachable commits
 (this branch is used by jk/maint-upload-archive.)

* jk/maint-upload-archive (2011-11-21) 1 commit
 - Merge branch 'jk/maint-1.6.2-upload-archive' into jk/maint-upload-archive
 (this branch uses jk/maint-1.6.2-upload-archive.)

Will merge to 'next' after taking another look.

Thanks. I also have some followup patches to re-loosen to at least
trees reachable from refs. Do you want to leave the tightening to the
maint track, and then consider the re-loosening for master?

I was planning to first have the really tight version graduate to 'master'
and ship it in 1.7.9, while possibly merging that to 1.7.8.X series. If we
hear complaints from real users in the meantime before or after such
releases, we could apply loosening patch on top of these topics and call
them "regression fix", but I have been assuming that nobody would have
been using this backdoor for anything that really matters.

On Tue, Dec 06, 2011 at 10:35:25AM -0800, Junio C Hamano wrote:

quoted

Also, let's drop the top git_getpass bits from the topic for now (they
will not be part of my rebase). They are a separate topic that can go on
top, but I think there was some question from Erik of whether we should
simply roll our own getpass().

Sounds sensible.

I suspect that there may be a codepath where we could ask both username
and password; instead of making two consecutive calls to getpass() or
git_prompt(), the series may want to give a higher level abstraction, so
that GUI can show a dialog with two input fields (single-line input and
password input) and interact only once with the user. Such an input widget
could _show_ the username, and optionally even let it edited (there may be
ramifications depending on how the codepath uses the username), while
asking for the corresponding password.

Yes, I've considered that, too. But I think the idea of a combined
username/password is part of the credential code, and the right
call chain is something like:

  credential_fill
    -> call helpers with "get"; return if it works
    -> credential_getpass
       -> call helpers with "ask" for combined GUI prompt
       -> otherwise, use git_prompt
          -> git_prompt("username")
          -> git_prompt("password")

So the "switch getpass to a generic prompt" idea is separate from
providing that higher-level abstraction.

quoted

quoted

* jk/maint-1.6.2-upload-archive (2011-11-21) 1 commit
 - archive: don't let remote clients get unreachable commits
 (this branch is used by jk/maint-upload-archive.)

[...]
I was planning to first have the really tight version graduate to 'master'
and ship it in 1.7.9, while possibly merging that to 1.7.8.X series. If we
hear complaints from real users in the meantime before or after such
releases, we could apply loosening patch on top of these topics and call
them "regression fix", but I have been assuming that nobody would have
been using this backdoor for anything that really matters.

OK. I'll hold back on the loosening then.

-Peff