Details about updated submodules

[deathaxe]

Problem description

A submodule is somehow like a library being linked to a repository. It is most likely a 3rd-party repository, which is not maintained by the top-level repository author. Hence the author does not need to know about all the details of the submodule but may be interested in updating it to its latest "remote revision" from time to time only without any interest in making local changes to the submodule at all.

While local changes to the submodule are displayed in the location bar, it is hard to see if and how a submodule was updated to its latest remote revision by calling git pull from within the submodule's working tree.

Preferred solution

location bar

The location bar should indicate the sources/nck submodule as being updated (newer than the commit in the top repository). Maybe it could display the ahead counters which are used to indicate the ahead/behind state of normal branches?

commit dialog

The hint text in the commit dialog should display the meta information about the submodule's new head commit. Maybe date, author, commit message?

This is how GitExtensions displays changes:

[TheClams]

I'd love to see something similar to what GitExtension Show, but more Sublime: the message To/From each collapsible and the difference for each file visible inline, like for any commit.

[n8gray]

Just a note to disagree with the assertion that "[The submodule] is most likely a 3rd-party repository, which is not maintained by the top-level repository author." In my work all of our submodules are in-house repos that are dependencies for multiple projects. I am constantly switching between working on the submodules and the parent modules. Any git client that makes that workflow less painful would get massive respect from me.

As for the proposal, I really want the improvements to the commit dialog (so I don't have to open up the submodule to figure out what the heck actually changed). I can take or leave ahead/behind counters, since I don't think they would work unless an upstream branch could be defined.

[deathaxe]

@n8gray: Just a note to clarify: "most likely" != "all" and "3rd-party" does not exclude "in-house", but just describes the circumstance for the main developer to not need to be the "main" maintainer of the submodules as well, especially if they are bigger projects as well.

We use submodules to include libraries which are maintained by different departments and/or externals, which does not exclude making PRs on submodules as well. But in most scenarios, they are just used as is. So a short overview about changes when switching to the latest release are of interest. So a short summery in the main repo would be nice.

But you are right: Everything which makes working with submodules more sublime/seamless is highly appreciated.

[themilkman]

As a "small step" towards this a suggestion:
Having an option on the ... button on near the "commit hash of submodule change" view (you know, where there is a text <submodule updated 223fa54f7f2ab021f3d1fee216087e6d396006a5 → 4246b7a02d2a17d66035f502756fb3eca684a68c>) which opens the submodule in a new tab and directly selects the two commit hashes to see the diff should be easy to implement but very helpful addition imho.

Edit: Opened new issue for this specifically: #1536