CloneOptions does not contains a definition of CredentialsProvider,,,

[sgagnier-hearst]

Reproduction steps

var cloneOptions = new CloneOptions();
cloneOptions.CredentialsProvider = (_url, _user, _cred) => new UsernamePasswordCredentials { Username = credentials.Username, Password = credentials.Password };
Repository.Clone(repository, repofolder, CloneOptions);

Expected behavior

Private repository to get cloned to local hard drive.

Actual behavior

Error message CS1061 'CloneOptions' does not contain a definition for 'CredentialsProvider' and no accessible extension method 'CredentialsProvider' accepting a first argument of type 'CloneOptions' could be found (are you missing a using directive or an assembly reference?)

Version of LibGit2Sharp (release number or SHA1)

0.29.0

Operating system(s) tested; .NET runtime tested

Windows 11, .Net Framework 4.8

[bording]

As mentioned in the change log, there were some breaking changes to CloneOptions as part of adding proxy support.

CredentialsProvider can now be found on the FetchOptions property on CloneOptions.

[kazakevich-alexei]

As mentioned in the change log, there were some breaking changes to CloneOptions as part of adding proxy support.

CredentialsProvider can now be found on the FetchOptions property on CloneOptions.

from this explanation, it is not clear at all what changes should be made. If you look at FetchOptions now, you won't see anything similar to CredentialsProvider there. Documentation, for example git-clone , immediately became useless.. Great, everything is very clear.... (no)

[mburtka]

As mentioned in the change log, there were some breaking changes to CloneOptions as part of adding proxy support.

CredentialsProvider can now be found on the FetchOptions property on CloneOptions.

The breaking change makes sense to me, but what was the rationale behind making the FetchOptions property on CloneOptions read only? I have a specific way of newing up FetchOptions in my app and not being able to assign means I'd have to change that logic to operate on an existing instance.

Do you have any opposition to exposing that either via setter or ctor? I'd be happy to submit a PR.

[gwsutcliffe]

I too am utterly confused by this change. Previously, I was creating a CloneOptions and setting CredentialsProvider in there. I can create a FetchOptions instead and set the credentials, but can't find any way to pass this into CloneOptions.

Please can someone share a fix? I'm passing in the credentials because the call failed without them.

[ethomson]

@gwsutcliffe Does this work?

Repository.Clone("https://github.com/libgit2/TestGitRepository", "/tmp/testgitrepository",
    new CloneOptions {
        FetchOptions = {
            CredentialsProvider = ...
        }
    });

[gwsutcliffe]

FetchOptions is read only (see the comment by mburtka above). This is the problem - your solution would be fine if FetchOptions could be set (and I wouldn't be posting here).

I've rolled back to v0.28 for now so as not to break my application's functionality.

[ethomson]

Ah, yes, I see, it was changed in November. In that case:

var cloneOptions = new CloneOptions();
cloneOptions.FetchOptions.CredentialsProvider = ...

should work, no?

(It looks like @mburtka was complaining about not being able to new up a FetchOptions - but I don't have any insight into the API design here.)

[mburtka]

Ah, yes, I see, it was changed in November. In that case:

var cloneOptions = new CloneOptions();
cloneOptions.FetchOptions.CredentialsProvider = ...

should work, no?

That does work, but I had a factory method to new up my customized `FetchOptions' using credentialing defined at startup. To upgrade I have to update that to operate on an existing instance:

var cloneOptions = new CloneOptions();
_fetchOptionsManager.Populate(cloneOptions.FetchOptions);

Instead of just newing up the FetchOptions with the CloneOptions. While it does work, it's ugly and is counter to all the other get/set behavior of the API.

[ethomson]

Instead of just newing up the FetchOptions with the CloneOptions. While it does work, it's ugly and is counter to all the other get/set behavior of the API.

Right, like I said, I don't have any insight into the rationale here. I don't know if @bording would be willing to review a PR here to change this back to have a setter, or if there's a philosophical or architectural reason to keep it readonly?

[bording]

Right, like I said, I don't have any insight into the rationale here. I don't know if @bording would be willing to review a PR here to change this back to have a setter, or if there's a philosophical or architectural reason to keep it readonly?

This was an intentional change on my part, primarily around the fact that I wanted to guard against the FetchOptions property from ever being null. I don't like APIs that have you create a type (CloneOptions in this case) that require you to create a new instance of a object, but then also require you to create instances of other nested types to actually make the original object valid.

That was why when I moved FetchOptions into a property of CloneOptions instead of how it was previously combining the various properties together, I decided to ensure the creation of the CloneOptions would also create the FetchOptions for it. And since an instance has been created for you, you would then set the individual options from the property as @ethomson demonstrated in #2075 (comment).

[mburtka]

@bording would you be amenable to having a constructor with either a null guard using the Ensure class used elsewhere or a coalesce-assign?

I new up my FetchOptions using a factory injected at startup (with credentialing, prune settings, etc..) and would prefer to keep that logic in the factory. But if you don't want to go that route I understand.

[davidsr2r]

Just creating links for the other issues by people facing the same issue.
#2087
#2088

To set the credentials correctly, see: #2075 (comment)