Repository-Tree: Updating status information

[antis81]

Some thoughts about a repository tree showing the complete submodule hierarchy (main-repo and sub-repos).

First, the big advantage of using a full repository tree is, switching between sub-repos and main-repo becomes possible. Plus, we could use it to show the status of each repository the same way.

I think of it as a "two-column-layout" first shows the repo-tree, second shows the repository content (history, worktree, diff, ...)

Each repository has basically the same status information:

• ID's: head, (workdir for sub-repos) and index
• dirty, clean
• difference to remotes (ahead, behind, divergence, ...)

When to update status information:

• When an item is drawn -> that's on widget.show(), scrolling, resizing - that would show the status correctly, most time
• Complete status update when we get the window focus.
• On a FileSystemWatcher event (should be lightweight, avoiding e.g 1000 status updates, when copying, deleting, ... multiple files)

From libgit2's point of view, we can just ask for the current status without getting a reliable "event".

[scunz]

I think of it as a "two-column-layout" first shows the repo-tree, second shows the repository content (history, worktree, diff, ...)

Would this be different from showing the current Working-Tree or History alongside with the current SubModules-View?

Some comments:

• Showing dirty / clean state ought to be trivial; we have to calulate it indirectly anyway. Should cache that information in gitWrap, though.
• Maybe we should simply show git describe (that would be last tag on that development line + # of commits since then + abrev. SHA1 of current state + dirty-flag).
• "Drawing", even if reduced to "show(), scrolling and resizing", is a heavy and time critical action. I doubt we should trigger a status update from within those places. Just imagine the trouble it might bring: Scrolling down 20 pixels could trigger an update telling us that we're not able to scroll anymore...
• The GUI definitifely ought to be up to date on gaining of focus (to the application, of course).
• As soon as we got FSW's, we won't need any other update mechanisms anymore. But that means doing each and everything event-driven.
• libgit2's PoV is actually not really clear to me. They would of course never say so; but our use case of the library is de facto simply not theirs. And actually, that's okay, but brings in some complications some times. Currently, we soley "wrap" the libgit2 API.
• Thinking a bit more about your last statement: We'd be required to have a caching layer built upon libgit2, in order to translate "ask for the current state" into "foo has changed it's sha, bar was deleted and foobar is a new frotz-object". (I doubt we can create an event "Anything changed" and propagate that everywhere without implementing much boiler plate in each and every "view")... But then again: Maybe such a layer isn't that bad at all.

[antis81]

I think of it as a "two-column-layout" first shows the repo-tree, second shows the repository content (history, worktree, diff, ...)

Would this be different from showing the current Working-Tree or History alongside with the current SubModules-View? Not sure if we mean the same thing here. The layout is close to that (I'd like to have a dock widget, but that's up to libHeaven :smile:). I'm talking about the functionality (replacing the history and, branches view by double clicking, but leaving the repo-tree untouched). This way we could switch repositories seamlessly, without loosing focus ever.

Some comments:

Showing dirty / clean state ought to be trivial; we have to calulate it indirectly anyway. Should cache that information in gitWrap, though.

Good! I'd like to show that as a separate "repo status" maybe make it look dirty, showing a broom with dust or something.

Maybe we should simply show git describe (that would be last tag on that development line + # of commits since then + abrev. SHA1 of current state + dirty-flag).

Seems like a good start. But I'd like to be more specific than just showing the "describe" string. But ok for the "Genesis" Version. (nice citing the bible :heart:)

"Drawing", even if reduced to "show(), scrolling and resizing", is a heavy and time critical action. I doubt we should trigger a status update from within those places. Just imagine the trouble it might bring: Scrolling down 20 pixels could trigger an update telling us that we're not able to scroll anymore...

Seems, I was - once again - unclear: I mean the request to QAbstractItemModel::data() (a.k.a as "the SubmoduleDelegate"). That would just make a call to "git_submodule_status" (isn't it cached already?).

The GUI definitifely ought to be up to date on gaining of focus (to the application, of course).

Yes, I just saw too many GUIs where you have to manually refresh in that case. But it should be the default.

As soon as we got FSW's, we won't need any other update mechanisms anymore. But that means doing each and everything event-driven.

Hm, maybe you're right. If I remember correctly, the current libgit2 implements an FSW as well. If so, we could make use of that and replace the current MGV implementation. I'll have a look at that.

libgit2's PoV is actually not really clear to me. They would of course never say so; but our use case of the library is de facto simply not theirs. And actually, that's okay, but brings in some complications some times. Currently, we soley "wrap" the libgit2 API.

Sometimes libgit2's PoV is not clear to itself :smile:. But yeah, totally agree. So ... let's just try to work with and not against it.

Thinking a bit more about your last statement: We'd be required to have a caching layer built upon libgit2, in order to translate "ask for the current state" into "foo has changed it's sha, bar was deleted and foobar is a new frotz-object". (I doubt we can create an event "Anything changed" and propagate that everywhere without implementing much boiler plate in each and every "view")... But then again: Maybe such a layer isn't that bad at all.

Yes, such a layer would be of great use in MGV. But maybe the whole status thing is too early for the "Genesis" version. Maybe some other things should be working first?

[scunz]

Thinking a bit more about your last statement: We'd be required to have a caching layer built upon libgit2, in order to translate "ask for the current state" into "foo has changed it's sha, bar was deleted and foobar is a new frotz-object". (I doubt we can create an event "Anything changed" and propagate that everywhere without implementing much boiler plate in each and every "view")... But then again: Maybe such a layer isn't that bad at all.

Yes, such a layer would be of great use in MGV. But maybe the whole status thing is too early for the "Genesis" version. Maybe some other things should be working first?

This is the most important part of it all. If we create such a layer, we should do it now. The earlier we do it, the less code will have to be "rebased" onto that layer.

libgit2 doesn't have any FileSystem watching and I doubt it will ever. FSW is hard to get right in an plattform-independent way (again, sadly, the Microsoft implementations are the only really reliable ones). Further, I don't think anyone in the libgit2 team thinks that this belongs into the library - I'm uncertain if that assumtion is right or not.

As for the SubmoduleDelegate... Well. You're totally right. git_submodule_status will give you some cached results. These might be up to date or just some ancient version. The same is true for many (actually not for all) places in libgit2. i.e. libgit2 has no list of refs. When you query the branches or tags, you get the current representation as fonud in the file system.

[scunz]

I'm talking about the functionality (replacing the history and, branches view by double clicking, but leaving the repo-tree untouched). This way we could switch repositories seamlessly, without loosing focus ever.

If i parse this right, you're saying:

• There is one view containing a list/tree view of the hierarchy of repositories (What we currently call Submodules-View). Let's call it the RepoTree.
• Then there are other views: Branches, Tags, Refs, RefLog, History and WorkingTree. [In my phantasy, libHeaven will allow to freely arange them on one/many monitors and/or windows in whatevery way pleases the user most. But that is just "wishful thinking" as of today)
• Changing the selection (or some "stronger action") in the RepoTree will change the context of the other views.

Right? As far as i can see, that's at least what Heaven::ViewContext will allow us to do, once it's done and integrated everywhere.

This, however, contradicts what I want to do with the "modes" in libHeaven. Currently we have just two of them: "Welcome" and the normal one. We switch depending on whether there is a open repository or not. But I actually invented this for merge-conflict-resultion / rebase / interactive-add scenarios. In these cases, a mode switch should happen and all views should disappear while the whole application is just covered by special views that allow to perfrom the desired action.

Another problem that has yet to be solved: Some view's context is not the repository. Currently, I can see two of such views: A Ref-Log Viewer and a Diff Viewer. Ref-Log can't currently be shown at all. Diff Views are integrated into History and WorkingTree Views. I think, that it would be way more clear, if we could have a View for "History", "WorkingTree" and one for Diffs. The context of the Diff-View is whatever is focused/selected somewhere else. The same applies to Ref-Log. A reflog depends on the branch it belongs to. A RefLog-View should change it's context when another Ref/Tag/Branch is selected. But such a RefLogView should also be able to be discoupled. I.e. this workflow:

• I badly messed up master and dev branches of my local clone by being half way through a complex merge including the rebasing of some branches... (I sometimes do such crazy things :smile: )
• I have the views "Branches", "History" and "WorkingTree" visible.
• In "Branches"-View, I select "master" and right click it. In context menu, I select "Show Ref Log".
• A new View "RefLog" opens. It shows the reflog of the master branch.
  1. Option here:
     • In "Branches"-View, I select "development" and right click it. In context menu, I select "Show Ref Log".
     • Context of the RefLog view changes. It now shows the reflog for "development" branch.
  2. Option:
     • In the Ref-Log View I select "Don't synchronize / Disconnect" option
     • In "Branches"-View, I select "development" and right click it. In context menu, I select "Show Ref Log".
     • A new (second) View "RefLog" opens. It shows the reflog of the development branch.

P.S.: Just realized: If we create this RepoTree, we could even try to allow to open 2 completely unrelated repositories at once.

[antis81]

Right? As far as i can see, that's at least what Heaven::ViewContext will allow us to do, once it's done and integrated everywhere.

Exactly, that's what I mean. I didn't realize that this would be possible to do with the Heaven::ViewContext. Hm, I'd be happy if you could prepare something in that direction.

This, however, contradicts what I want to do with the "modes" in libHeaven. ...

Well, not really. A rather "ugly" solution would be to workaround this by using modal dialogs - but I also really prefer the idea of using the modes, mentioned by you, instead and keep everything in a single application context.

P.S.: Just realized: If we create this RepoTree, we could even try to allow to open 2 completely unrelated repositories at once.

We're getting there :+1:. It's a great advantage to have everything at one place without having to switch applications or worse - the terminal (Btw.: an integrated terminal with abilities to execute additional custom scripts would be ass kicking :smile: - ok, back to topic).

All in all, I agree with you in every point and it sounds cool, with great potential. So just keep going :smile:. The RefLog View is another great idea. Are you planning to implement it already in the first version? I'd suggest to prepare it for the next version and concentrate on the basic things.

[scunz]

Heya, @antis81, I've been thinking about few of the topics mentioned herein quite a lot. During that, I realized, the ViewContext-Thingie is not as easy to implement as I thought. I've detected some conceptual mistakes that I've built upon. I'm right now in the progress of overhauling libHeaven and hope to have some results ready by the end of the week...

[antis81]

Sounds great, thanks :+1:

[scunz]

Parts of this discussion relates to #5, which I think might be done by the end of the next week :-)

[scunz]

End of next week? Heya, then I'm still on schedule :-)

RepoTree is basically done. No actions from within RepoTree, yet.

[antis81]

Not bad. At least it is not behind the previous solution :smile:.

[scunz]

There's no delegate, yet. So it's probably a bit behind, though. I'm just about to once again put many files into their "righteous" place, so that we can keep things that are internal to the Core actually internal in the Core...

[antis81]

Uhm, didn't re-read the whole thread, but I think we can close it as most of this is implemented and no more relevant.