Allow passing parent directory to git.clone command

[vially]

I'm working on a Visual Studio Code extension that's supposed to make it easier to clone a git repository in a user configured directory.

The basic idea is that the user configures the clone directory once (e.g.: in settings.json) and then all the cloned repositories will be placed in this directory.

The git.clone command seems the ideal candidate for implementing something like this (especially now with the new awesome progress bar). However, the only problem is that the git.clone command is always interactively asking the user for the destination directory.

This feature request is about adding an option to the git.clone command which would allow other extensions to clone a repository in a specific directory without showing the Select Repository Location dialog.

One possible implementation could be as simple as adding another optional argument (for the destination directory) to the git.clone command (#85459).

[connor4312]

Found a quirk: https://github.com/microsoft/vscode/pull/85459/files/1ae9ff4cb19c57bc061712b843b07f6e2cdc173f#diff-344b8481439db2d9949984cbd9332879

[isidorn]

Fixing the quirk is fine in the future. Thus pushing it out to the On Deck milestone since Joao is on vacation.
@connor4312 please speak up if you disagree.

[grdowns]

+1 for this issue.

I'm also working on a VS Code extension (specifically the C++ extension here in Redmond). We're working on an experience that involves operating on the files in a repository that the user has cloned via the git.clone command, but currently there is no way to know which parent directory was selected.

Allowing the repository parent directory to be passed in would solve the problem entirely for us -- I'll be watching this issue closely. 🙂

[vially]

@grdowns This has been implemented (#85459) and you can already use it in Visual Studio Code version 1.41.

[grdowns]

Thanks @vially!

[isidorn]

Since this is already implemented I am closign this issue.
Thanks
As for the quirk @joaomoreno can handle as an independet issue

[rzhao271]

@isidorn @connor4312 should this issue be labelled with verified again?
I also wonder if the quirk has been filed as a separate issue. @joaomoreno