On Sat, 28 May 2011 11:49:11 +0200 Rémi Vanicat <[email protected]> wrote:
>> Also my original message asked about askpass; that's much more reliable >> than parsing CLI output and works in Unix and Windows (with msysgit at >> least). Could Magit support that? RV> For this to work we need a script that call Something like RV> #!/bin/sh RV> emacsclient -e "(magit-ask-password \"$*\")" RV> where magit-ask-password would be a new function dealing with the actual RV> asking. RV> Then if we setenv SSH_ASKPASS to it, both git and ssh will use it for RV> asking password. (If we want this only for git it's GIT_ASKPASS we have RV> to set) We should do both (the HTTP transport is important). RV> problems with this are: RV> - this might not work as easily on windows and Mac OS X RV> - we will need to install this script somewhere. It make magit RV> installation more complex, particularly for user of the git version RV> and those who install themselves. It will work on Mac OS X, emacsclient works there and so do shell scripts. On Windows I can provide a tcl/tk based askpass (cloned from the standard one and adding some trivial password encryption) that works in msysgit. The script for Unix systems is very trivial. It could be created at the time it's needed as a temp-file. RV> An advantage would be to get ride of the problem that make us use RV> magit-process-connection-type and just use nil for its value. Of course, and you could keep using the old approach on Windows if the tcl/tk approach doesn't work there. >> It may be productive to give me commit access to the Github repo as I >> have some other Magit things in my queue. It's not a big deal, just >> don't make me do the Github-specific fork+pull request procedure :) RV> I will look at your code later, but please, do fork and request RV> pull. It's really easy, and it's our standard procedure for dealing with RV> new contributor and review there code. RV> It's also the place where I go when I want to look at code review I RV> wanted to do and forget. I really don't like to use and depend on Github (hence my request to avoid it earlier). Is there something wrong with submitting patches? I prefer the clarity and transparency of the patch-based process, plus patches in an e-mail leave a record in the mailing list instead of a vague trail somewhere on the web. Ted
