Use separate icon/badge for Submodule in Changes lists

[goran-w]

Currently, a Submodule change in the Unstaged/Staged areas, and in the Changes for a Commit etc, are using the same ± icon/badge as ordinary text/binary file changes.

Meanwhile, in Diff, Conflict etc the Submodule type needs special handling and display. Also, the Submodules even have their own category in the left sidebar. Thus, it would make sense to distinguish these using a separate icon/badge, i.e with a separate symbol S (or similar) and a separate background color.

This would be very helpful, allowing us to more easily spot any Submodule changes among a potentially long list of changes.

[love-linger]

I don't agree with this view. On the contrary, I think it's correct to keep the icons consistent. Currently, SourceGit keeps the icons for changes consistent, but presents different changes (such as plain text files, Binary, Image, LFS, Submodule, etc.) in different ways.

[goran-w]

I agree that text, binary, LFS should all use consistent icons, since they are all regular files (except LFS, but these should ideally be treated rather transparently as diffs of the actual target file). However, a submodule is a different filemode, and its change is referencing a revision of changed content elsewhere so it's more like a meta-change.

They are handled a bit strangely by Git during conflict-less merge, where an incoming submodule change appears both as a Staged change AND an Unstaged "reverse" change. So usually we need to Discard the Unstaged one. This also makes it important to distinguish them.

Additionally, because it's not a regular file, it makes (most existing) external merge tools fail - this is why it's crucial to distinguish them also during conflicts, so they can be handled first (before optionally running "Open all conflicts in external mergetool").

[love-linger]

The key idea of this app is makes it simple to use git.

I just want to let users know there's a conflict in given path. If they want to know the detail information of the conflict or to resolve it, they can go to the conflict view to see and use options provided in conflict view.

--

Sorry, replied to wrong issue.

[goran-w]

Actually, git-status also treats submodules a bit special:

Submodules have more state and instead report
M = the submodule has a different HEAD than recorded in the index
m = the submodule has modified content
? = the submodule has untracked files
This is since modified content or untracked files in a submodule cannot be added via git add in the superproject to prepare a commit.

And when using the git status --porcelain=v2 it even return a special 4-char <sub> field for submodule state:

"N..." when the entry is not a submodule.
"S" when the entry is a submodule.
is "C" if the commit changed; otherwise ".".
is "M" if it has tracked changes; otherwise ".".
is "U" if there are untracked changes; otherwise ".".

NOTE: I'm NOT asking that we indicate any such additional C/M/U status from inside the submodule, I'm ONLY asking that we indicate when the pending Change IS a submodule-change (i.e NOT a normal file-modification) - basically the S (vs N) info from Porcelain Format Version 2 (or possibly gathered from elsewhere, like checking the Change path against the known submodules, but that might miss an Added/Deleted submodule).

[goran-w]

OK, sorry, I just realized that we (of course) need to distinguish between Modified/Added/Deleted/(Renamed?) for submodule Change.

But could there then instead be ANY (other) indication in the list that a Change is a Submodule?

[goran-w]

A grayscale submodule (box/package) icon to the right of the submodule name/path would do fine.

[goran-w]

I.e. something like this would be fine, just some (any) indication that a change-list item is actually a submodule...

Could also be placed to the left of the name/path, just like in the left sidebar, if you prefer - I don't mind where it's placed, as long as the submodule-indication is there in the list of changes!

NOTE: The one immediately to the right of the name/path would be placed before the dir-part when using the Show as File and Dir List option. Maybe that's OK, though...