Closed antis81 closed 10 years ago
The sorting stuff looks good.
For the branch renaming: I'm not sure that it is a good idea to let the user change the branch name in place in the tree view.
P.S.: I'm actually about to create a generic Proxy Sorter with some MGV specific features inside libMacGtiverCore... But will take a few days...
P.S.: I'm actually about to create a generic Proxy Sorter with some MGV specific features inside libMacGtiverCore... But will take a few days...
Great! I added sorting to the RepoTree also. This is basically working, but has some flaws still. It needs cleanup within the repo model and RepoInfo signal/slot handling.
For the branch renaming: I'm not sure that it is a good idea to let the user change the branch name in place in the tree view.
Renaming of branches should certainly be improved. I'm fine with the current solution for 0.1, if you don't mind. I agree, it was not intended, that the complete path can be changed here. Further, it should be possible to synchronize the renamed branch with with the remote repository(s). Therefore we need some kind of dialog.
I added sorting to the RepoTree also. This is basically working, but has some flaws still. It needs cleanup within the repo model and RepoInfo signal/slot handling.
I already did that at the beginning of the week :collision: :collision: :-)
For the renames: um, well, I actually didn't think so far: But you're right this is a sleeping beast and deserves a dialog :-)
@scunz Please review and comment.
References are now renamed in a separate dialog by using their "shorthand". Still this is just the tip of the iceberg. We need a real smart mechanism to synchronize the remote refs. But this is a bigger topic deserving a single PR like "much improved renaming of references". I'd leave that one for 0.2. For this reason I did not include any placeholders and such things.
@antis81, could you merge this one in quickly but without hurry :-)
Actually, I finally started refactoring the repository manager, so this will soon clash...
@scunz To keep things easy, feel free to merge this in favor to the refactoring. I have made only few changes yet according to our latest discussion. No need to hurry or worry :). I'll open a new PR then to get the changes right.
This is going into the right direction anyway, but might probably be revisited when I'm done with the RepoMan refactoring. I'm going to merge this in order to not lose this changes.
Ups, I think, I just killed your PR while you were still adding to it :8ball:
Ah, just one minute too slow :smile: - added the check on detached head. Would you please merge.
Good to know that git never loses anything unless you really, really, really badly tell it to... :-)
-- sacu@sammi Mo Sep 23 23:25 /work/mgv/src/MacGitverModules (development u=)
$ git cherry-pick 6a0f
[development fef5e20] check if repo is valid and head is not detached before trying to highlight the current branch
Author: Nils Fenner <nilsfenner@web.de>
1 file changed, 15 insertions(+), 3 deletions(-)
-- sacu@sammi Mo Sep 23 23:25 /work/mgv/src/MacGitverModules (development u+1)
$ git push
Password for 'https://scunz@github.com':
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 757 bytes | 0 bytes/s, done.
Total 5 (delta 4), reused 0 (delta 0)
To https://scunz@github.com/macgitver/MacGitverModules.git
b22eca6..fef5e20 development -> development
Originally I was thinking about the "detached head problem" mentioned by you. Then I found a method is already implemented in GitWrap. So I just added the few lines some minutes ago and also changed to "RepoMan", which makes refactoring probably easier. No other changes in the queue.
Yepp, that's fine.
So let's see, if I can still rebase without trouble...
Went almost smoothly. Just one include related compile error introduced into my branch.... :-)
Hm, yeah cool. Battery empty - cu :)