Open antis81 opened 9 years ago
@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.
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:
These are the most extreme ones. Everything between them is actually very valid, too. i.e.:
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:
x
and branch x
has an upstream assigned. Fine, I can do this without further info.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. :)
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.