A better SubmoduleStatus?

[nulltoken]

As discussed in #1103 (comment)

Maybe should we

• Move Submodule.RetrieveStatus() into SubmoduleCollection.RetrieveSubmoduleStatus()
• Turn SubmoduleStatus into a concrete type, which would expose IsUnmodified and IsWorkingDirectoryDirty shortcut properties along with another one which would maybe expose the flags? This may leave us some room for future improvement (conflicts, ...)

Quote from @dahlbyk

"Now that you mention it, I agree that the SubmoduleStatus API has some room for improvement (SRP violation, communicating both superproject and submodule status)."

[shiftkey]

I like the direction this is heading 👍

[nulltoken]

Do we need this for the first major release? If that's the case, we should agree on a quick proposal (type name, name of the property exposing the current enum, ...).

Otherwise, I'll drop the stabilization label in the next following days.

[dahlbyk]

I would be in favor of not exposing the underlying enum if we can avoid it. It looks like there are really three kinds of status, though naming them is tough...

1. Superproject config status (In Head, Index, Config, WorkDir)
2. Superproject tree entry status - am I missing something or could this be represented with a FileStatus (with git_status_t in libgit2)?
3. Submodule repository status (clean, index dirty, workdir dirty, untracked files)

[whoisj]

I'm also on the side of having this at least defined before we reach v1.0. From my PoV, there will be significant costs to any API changes and mountain moving costs to breaking API changes once we hit v1.0.