search

macgitver / MacGitverModules

DEPRECATED: Modules for MacGitver
5 stars 1 forks source link

Feature: reference view context menu #64

Closed antis81 closed 11 years ago

antis81 commented 11 years ago

depends on macgitver/libGitWrap#19 (merged !)

scunz commented 11 years ago

@antis81, you should just have received some automatic emails that enable you to look into some of the work I did on MGV before I paused. Yonder there the features/custcom branch involves solving a problem similar to this one. Maybe you can get some inspiration from there.

antis81 commented 11 years ago

Phew, I'm really trying to understand what's going on here and it seems that we have some questions to discuss here. I would be glad for some help, if you could squeeze out some of your precious time :smile:!

  1. To me it seems there's some duplicated code fragments for the same thing. There's the RefsViews/RefsListModel.h and the RefsViews/Branches/BranchesModel.h, both a slightly different subset for references - why? Maybe we are better of with a filtered model like in WorkingTree. What do you think?
  2. When using the ReferenceInfo struct. Why not wrapping the data object "Git::Reference" and carry it to the top instead of cutting away essential information on that?

I am just doing implementations in GitWrap to access Git::Reference information (feel free to look at libGitWrap/feature/RefsImprovements). EDIT: Sorry, I mean the PR over there macgitver/libGitWrap#19

scunz commented 11 years ago

I would be glad for some help, if you could squeeze out some of your precious time :smile:!

That's the least I can and will gladly do :-)

both a slightly different subset for references - why?

Historic. Feel free to clean up my mess.

When using the ReferenceInfo struct. Why not wrapping the data object "Git::Reference" and carry it to the top instead of cutting away essential information on that?

When using a really recent version of libgit2, there's no problem, i guess (or hope at least). I can still remember the git_references objects that liked to destroy themselves without further notice... Which reminds me: What's the current up-to-date-ness of our libgit2 submodule? I know at least I didn't update it for a really long time; and I occasionally see the failing in Jenkins...

The Ref-Improvements Branch looks good to me. Nice work.

By the way: Did my mail reach you or did I screw this one up again? :-)

antis81 commented 11 years ago

For the mail, everythings fine. Push/Pull works. There's this "problem" with submodule links though, as they can only point to a single location, or do they?

For lg2: Good news. We are brand new -> v0.19 which is planned to keep a mostly stable API :star:. So I go on with this one, having a good feeling on relying on the "original" objects as far as possible.

scunz commented 11 years ago

There's this "problem" with submodule links though, as they can only point to a single location, or do they?

"to a single location at a time", yes. However, the url given in .gitmodules is meant to be a default value only. You can at any time exchange it in the .git/config. Actually I could imagine a dozen ways to improve this. But talking to git folks is like... hum, well. The base line is: You could as well talk to a mirror.

Does GitWrap still follow libgit2's development branch?

antis81 commented 11 years ago

Does GitWrap still follow libgit2's development branch?

Yep, it does - well, after I did some minor changes to it :smile:. Currently there seems to be another build problem, but I want to wait for the next major release before fixing again. It's simply too much to handle, following changes of a hundred developers just to be on the edge. Turned out, this is a not so bad strategy, letting us sleep well :sleeping:.

For the Git folks: I think just discussing new ideas mostly don't lead to results. The big deal is to show others the value of doing something different. It's just simple: Nobody likes to do the work if it is not worth it - or if no :moneybag: is given as a motivational factor. It seems like a steep mountain to climb. A manager would say "we don't have the resources to do that". But let's say someone walked a third of the mountain, maybe another one can understand the value and they walk the rest together. Here's some cite I found in the ev. Gesangbuch, which I :heart: very much: „Wenn Du ein Schiff bauen willst, dann trommle nicht Männer zusammen um Holz zu beschaffen, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre die Männer die Sehnsucht nach dem weiten, endlosen Meer.“ - I think that says it very well!

scunz commented 11 years ago

Does GitWrap still follow libgit2's development branch?

Yep, it does - well, after I did some minor changes to it :smile:. Currently there seems to be another build problem, but I want to wait for the next major release before fixing again. It's simply too much to handle, following changes of a hundred developers just to be on the edge. Turned out, this is a not so bad strategy, letting us sleep well :sleeping:.

Yipp, now that they actually do some releases now and then, makes sense to change GitWrap's update-policy. But with almost a year between .17 and .18 it was actually more pain to be not on the edge :-)

I need to remember that citation. It's actually a very good one... However, wrt. to the git folks, I must strongly disagree. For sure, git is one of the greatest inventions since the wheel, but it's developer community is like a rotten tomato. I've actually been following their mailing list very closely for quite some time. There have been many attempts in fixing SM stuff; most of them have been rejected, even though code was available. Submodules are not the only area where this happens. You know me: If I have an idea, am convinced of it and able to implement it, I usually don't give up unless it's actually "done". But I would not even try that, if the subject is "git". Just because it's almost impossible to get something bigger into git unless you're part of some inner circle. This inner circle defends itself strongly and effectively against any kinds of intruders. This is sad, but after having read almost all of the 50.000 mails that are currently inside my "Core-GIT" mail-folder, I'm unable to draw any other conclusion...

antis81 commented 11 years ago

Hm, lots of changes. Sorry for the mess, but I simply had to upload these. Still not perfect, but cool.

See glimpse: screenshot_mgv_refs

antis81 commented 11 years ago

I'd like to merge this one here. The basic features are complete (see PR tasks). There are some flaws still, but none of them is destructive in any way. E.g. the "checkout" is a little too picky about conflicts and such things.

There's still the bigger question of how to synchronize the views in a painless and cool way. But I'd rather make up another issue, if there isn't one yet.

scunz commented 11 years ago

Looks like you need to rebase onto development (again) first.

Other than that and with the "unfinished exceptions" you already stated, I think that this can go in... But this reminds me again that we really really need some finished color management inside libHeaven.

antis81 commented 11 years ago

Yup, this is really small changes in the development branch to keep it build- and runable.

scunz commented 11 years ago

@antis81, I've done the rebasing and pushed it to feature/Rebased-ReferenceView. Please review it there and if okay, force-push it onto the feature/ReferenceView branch in order to inconspicuously update the PR with the rebased code.