A better SubmoduleStatus?

Open
#1,121 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Stale
Tech stack
csharp, git
Domain
backend-api-design

Research direction

Start with the linked discussion in issue 1103 and inspect the existing Submodule.RetrieveStatus(), SubmoduleCollection, and SubmoduleStatus APIs. The issue does not name files or tests. Done would require an agreed API redesign covering status ownership, shortcut properties, and future status flags.

Written by the indexing model from the issue text.

Description

Stabilization

As discussed in https://github.com/libgit2/libgit2sharp/issues/1103#issuecomment-113903882

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)."

Dominant language
C#
Stars
3.5k
Forks
925
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from libgit2/libgit2sharp

All issues in libgit2/libgit2sharp

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.