fetch remotes of a repository

[antis81]

Some thoughts about this PR: It is not a good idea to realize the remotes menu in a central place. Why? Because from a users point of view there is no obvious context (What am I fetching/pushing from/to where? To which repository will a new remote belong?). Also the options to the fetch process are context-specific. The actions should actually be added to the appropriate context menus. For example a "fetch action" on a remote branch, fetches the remote branch. IOW: This belongs to the Reference-Tree and probably to the inline remote references in the History-View (we don't have a context menu for them yet). The actions itself should be defined central in the "Remotes" module, which should provide a the generic remote operations and just needs to be attached to the appropriate context. For this reason, the concept of the DAM (Dynamic Action Merger) has to be fully implemented first. This PR has to be hold back until then.

This is how it could look like?

Planned for this PR:

• [x] Fetch all remotes.
• [x] Fetch a single remote (only when more that one remote are configured) :memo: Another PR will be created for this after integrating the MacGitverModules submodule.

Excluded from this PR

• Move actions from "Remotes" application menu to the appropriate context menus.
• Fetch a single branch. This is planned as an action for the "Reference-Tree" (and the inline references in "History-View"). See ticket on ![Redmine]()

More Ideas:

• Prune remotely deleted branches (aka git fetch --prune). One idea is, to provide a "Cleanup" context menu to the repository tree, with options "Prune Branches", "Garbage Collection (gc)", ...
• add a flag or option to recurse into submodules -> this clashes somewhat with the git config.fetch.recurseSubmodules flag.

[antis81]

@scunz This is ready to merge.

EDIT: FYI. To make life easier, I moved this PR from sc/refsview back to development. It will not compile, due to the small changes, that went to the wrong place. I don't care and move on anyways.

[scunz]

No, this is not ready to merge. Please hold off until I finished my mail - then you'll understand why - but it's taking ages to do that :)

[antis81]

Yeah, I know this is unfinished stuff. I just want to trigger the merge as soon as possible, to help getting the submodule integration done quickly, before this gets into a more complex discussion and delaying things until next year - ya know what I mean :).

[antis81]

Closing, as this is a POC, not a final implementation. Moved to new PR #104 taking a different approach to abstract remote operations in a separate MacGitver module.

EDIT: I'll keep the branch to not lose the code.