Realization of remote actions in "Remotes" Module

[antis81]

The single purpose of this PR is to realize (complete) the abstraction layer for user actions to a repository's remote components. This affects the remote operations "fetch", "push", "clone" and "pull".

The focus is clearly on the fetch operation first. The already existing clone operation has to be also integrated here, but this is another topic and works as is.

[antis81]

@scunz With the latest changes here we have kind of the same state as in PR #101 now - plus the basic frame to realize all the remote actions in the "Remotes" module. And I think it looks quite promising right now :smile:. Please let me know, if this matches your imaginations.

I'll leave out the progress dialog for now, because we have to solve another topic first. The progress dialog is partly implemented within the clone action and sleeps in the "Repository" module - the right place for it is most probably the libMacGitverCore/Widgets -> see Redmine.

What I'm thinking about is to create a central action, that behaves slightly different, depending on the calling context (the menu item). I'll pick the "Fetch All Remotes" case out to show what I mean. In terminal one could write something like this:

# Case 1 - "repo context": Fetch all branches from all remotes
$ git fetch --all

# Case 2 - "branch context": fetch a single (remote or local) branch from all remotes
$ git fetch --all --single-branch='ngf/feature-branch'

Case 1 is implemented now and can be called from the context menu on a "RepoItem" (in the repo tree). As soon as your sc/refsview branch got merged, I think of providing the "fetch" menu for case 2 in the "RefsTree". This adds some opportunities, because we have local/remote branches and the very remote items. I'd like to use these items as a "calling context" to setup the action with the right parameters for the context.

[scunz]

Okay, let's have some high-level chat about this (also considering the recent emails):

First of all, I like the idea of having different entry points into actions like fetch, push, branch, tag, foobar. This is what I've always wanted :)

Second, let's look at some things that will provide lots of benefits to the user in form of User-Stories:

• As a user when I do day-to-day work I want a simple and quick way to fetch, so that I can make my remote settings once and don't need to further bother about them
• As a user when I need to publish my source somewhere else I want the full flexibility of the command line so that I don't need to dive down to my terminal.

These are the most extreme ones. Everything between them is actually very valid, too. i.e.:

• As Mr. Torvalds when I made a new Kernel release, I want to push the master branch and my new tag to 10 different places in one go.
• As Mr. Torvalds when I get a pull request from someone, I want to fetch those changes to my local repository but do not want to create a remote for that single fetch.
• As a power user in a peer-to-peer development style, I want to fetch from my coworkers but their IP address changes once a week and they got no DNS name.
• As a beginner when I was told by my friend that I should generally clone from code.qt.io but pull from gerrit occasionally and definitely push to gerrit.
• As a gerrit user, I want to push a detached commits to a specific reference that never changes.

These are very interesting use cases. All of them can be very easily solved: We just need to setup a funnel, where the code-flow must go through. At the output of that funnel, we'll always have the same code - but on the input-side we can come from very different contexts and this wording is not coincidence :) ...

We also have a default context (the currently active repository), thus these actions can (and actually have to) be globally available.

So, now I right-click on:

• Repository: A repository context is given into the funnel. The funnel decides: I'm on branch x and branch x has an upstream assigned. Fine, I can do this without further info.
• Repository: A repository context is given, but there's default branch or it has no upstream. The funnel decides: gather that information together and show the fetch dialog
• Branch: Same as above, just limited to a branch
• ...
• If I go there from the main menu, by default the funnel will always show the dialog (but I can instruct it to just do the "default"-thing).

IF I press the shift-key during activation, the funnel will gather my information and unconditionally show the dialog.

All of these code paths follow the same flow...

The next thing is, the code in this PR isn't taking the problems of the last one into consideration. It still uses libGitWrap and - as I explained - this is a no-go.

I'll leave out the progress dialog for now, because we have to solve another topic first.

The progress dialog is an essential part of this - and, honestly, nothing of this code can go "live" before "the other problem" isn't solved. We're doing ourselves no favour when we're keep on acting otherwise. :)