CloneOptions does not contains a definition of CredentialsProvider,,, about libgit2sharp HOT 13 OPEN

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.)

from libgit2sharp.

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).

from libgit2sharp.

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 libgit2sharp.

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)

from libgit2sharp.

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.

from libgit2sharp.

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.

from libgit2sharp.

@gwsutcliffe Does this work?

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

from libgit2sharp.

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.

from libgit2sharp.

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.

from libgit2sharp.

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?

from libgit2sharp.

@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.

from libgit2sharp.

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

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

from libgit2sharp.