code slightly refactored to be more readable;
tests for commit run locally for http, https
SSL client certificate dialog to be initialized with stored client file value
code notes: 1) now we pass "is password" parameter read from command line err output to switch between password and client certificate types
2) we store client certificate path in servers file - as by spec, but svnkit doesn't do that somewhy
3) we also store client certificate passphrase in Subversion native format, overriding svnkit behaviour, which seems to be wrong (realmstring -> client certificate path)
`git log --branches --tags --remotes` doesn't count the current HEAD
if it is detached. To fix it, show the log from the HEAD:
`git log HEAD --branches --tags --remotes`
Show all commits that are in the given branch,
but not in any remote branches in the given remote:
`git log new_branch --not --remotes=origin`
This fixes IDEA-83227.
* Keep the code under a Java system property until native Git support
for HTTP connection is tested.
* Remove NetrcData since it is not needed anymore.
Use native command line Git for HTTP connections via GIT_ASKPASS
environment variable, to be able to get rid of the JGit library.
Method description.
The communication logic is very similar to what is already
implemented for SSH connections.
* Define the GIT_ASKPASS environment variable pointing to a script
generated by the ScriptGenerator.
* When Git requests username and/or password for an HTTP connection,
it calls the script defined in GIT_ASKPASS.
* The script starts the Java application GitAskPassApp and passes the
Git request to it as command line arguments. Git process waits for the
app to return user credentials to the app's stdout.
* GitAskPassApp requests the credentials via XML RPC from the main
IDEA instance by calling correspondent methods of the
GitAskPassXmlRpcHandler.
* Before Git command is called, a GitHttpAuthenticator is registered in
the GitHttpAuthService to receive any XML RPC requests about HTTP
authentication.
* Once the XML RPC request is received, the GitHttpAuthenticator
either takes the password from the password safe, or shows a prompt
to the user in a modal dialog.
* Response is provided back to the GitAskPassXmlRpcClient, which returns
it to the GitAskPassApp, which in turn returns it to the Git process.
GitHttpAuthenticator details:
* The key for password safe is url + login (see makeKey()).
* If password is asked, then the URL contains the login inside URL,
and the key is ready.
* If username is asked the key is constructed and is searched for in
the settings (GitRememberedInputs).
* If no username is specified in the URL, Git queries for the username
and for the password consecutively. In this case to avoid showing
dialogs twice, ask for both credentials at once (AuthDialog) and
remember the password to provide it to the Git process during the next
request.
* We can't store the credentials enter by user in the settings and
the password safe right after they have been entered, because user
can enter incorrect credentials.
Therefore, listen to the Git process output
(GitHandler#addAuthListener) and analyze whether authentication
was successful or failed. If it was successful, ask
GitHttpAuthenticator to remember the correct credentials, otherwise
forget them (since they could have been taken from the password safe,
not from the user).
* Because of this, all other data (url and login, or url with login
if the password was requested) is saved to the instance fields.
This change fixes all issues opened because of JGit problems:
* authorization issues: IDEA-97178, IDEA-102201, IDEA-100617,
IDEA-98189
* connection and proxy issues: IDEA-83984, IDEA-92519, IDEA-96205
* IDEA-77411 self-signed server certificates (although we can provide
more user-friendliness by proposing to set http.sslVerify to false
in the UI).
* IDEA-100096 client SSL certificates.
* other: IDEA-78744, IDEA-77992, IDEA-76982, IDEA-78310, IDEA-86083,
IDEA-92163, IDEA-94167, IDEA-99159, IDEA-100097
Known drawback:
No retry. If user enters incorrect credentials,
he will see the failure notification and will need start operation again
to supply correct data this time.
Rename GitSSHService to GitXmlRpcHandlerService and let it be the base
abstract class parametrized by the actual GUI handler.
Move SSH-specific code to the first implementation: GitXmlRpcSshService.
* Clone, fetch and ls-remote are trivial: just pass the url parameter.
* Pull: modify the method signature, since it can return pull or merge
handler depending on the situation. For merge url is not needed.
* Standard Push (GitPusher):
- simplify the logic by taking the first url
instead of iterating over all of them,
because we don't support pushing to several urls very well anyway.
- report error if there are no push urls: GitPusher shouldn't be
called in this case at all.
* Push when remote branch is deleted (GitDeleteRemoteBranchOperation):
same as for the standard push: take the first url,
report error if there are no urls defined for the remote.
* Set remote protocol to null by default => safely remove all 82 calls
to setNoSSH.
* For remote operations (pull, push, fetch and clone) set the protocol
to SSH (HTTP is handled separately for now).
This is a preparation for working with HTTP via native Git.
anna
Alexander Zolotov
Bas Leijdekkers
irengrig
Alexey Kudravtsev
peter
Max Medvedev
Vassiliy Kudryashov
Dmitry Jemerov
Kirill Likhodedov
Eugene Zhuravlev
Konstantin Bulenkov