Remote tracking branches pruning

[nulltoken]

libgit2/libgit2#2761 has been merged and brings a lot of niceties!

We may now expose the following

• remote.ShouldPruneOnFetch { get; }
• remoteUpdater.ShouldPruneOnFetch { get; set; }

Along with some basic test coverage to ensure everything works as expected

[nulltoken]

#695 was about "on demand" pruning.

[jamill]

alternatively return shouldPruneOnFetch ?? false;

[nulltoken]

shouldPruneOnFetch holds a ConfigurationEntry, not a bool, so I'm afraid this shortcut wouldn't work here.

[jamill]

Is the purpose of remote.ShouldPruneOnFetch { get; } is to return the prune behavior when fetching the remote? If so, I think we will have to take into account the configured fetch.prune value (if any), if the remote.<name>.prune option is not set.

[nulltoken]

Is the purpose of remote.ShouldPruneOnFetch { get; } is to return the prune behavior when fetching the remote? If so, I think we will have to take into account the configured fetch.prune value (if any), if the remote.<name>.prune option is not set.

@jamill I've thought about this as well, but was unsure about the outcome. Are we trying to determine if this remote is configured to prune on fetch, or we we trying to determine if the next fetch against this remote is going to prune?

Thoughts?

Whatever the option we will choose, the xml doc should be updated to reflect the underlying logic.

/cc @carlosmn

[nulltoken]

TODO: Add some description about the logic when we reach an agreement (also consider fetch.prune or not?)

[jamill]

Are we trying to determine if this remote is configured to prune on fetch, or we we trying to determine if the next fetch against this remote is going to prune?

I would expect this to tell me if fetching from this remote would prune. I would find it unexpected if ShouldPruneOnFetch returns false, but when I fetch pruning actually happens.

If all this is doing is providing a convenience to read off the remote.<name>.prune option, then maybe the method name should be even more specific...

[nulltoken]

@jamill PR has been updated. Better?

[jamill]

Would we also need a way to clear this value? maybe this is just a Getter property? And possibly expose a method that can set true, false, or clear it (or just force setting to go through the repo.Config.Set)?

[nulltoken]

As the getter is a combined value, this setter is now confusing. Let's drop the RemoteUpdater implementation for now.

[carlosmn]

this remote is configured to prune on fetch, or we we trying to determine if the next fetch against this remote is going to prune?

Determining that would require a git_remote object plus knowing what options are going to be passed, as you would be able to override the option (not sure if it's implemented in lg2s yet, but it's one of the variables when dealing with git_remote).

I would go with looking at the configuration (as you have now) since I plan to remove the setter from git_remote.

[jamill]

Determining that would require a git_remote object plus knowing what options are going to be passed, as you would be able to override the option

Yeah - I meant what the default behavior would be without passing in any options to override the default behavior (I tried to capture this with AutomaticallyPruneOnFetch property name).

I would go with looking at the configuration (as you have now) since I plan to remove the setter from git_remote .

Not sure I follow - which setter you are removing? The ability to override this as part of a fetch? The ability to set this config value through git_remote?

[carlosmn]

I mean the git_remote_set_prune() function. There is no way to set this config value through a git_remote. The ability to choose whether to prune will still be there, in a different way.

[coveralls]

Changes Unknown when pulling 2d5cdda on ntk/remote_prune into * on vNext*.