You can access a Submodule's detailed configuration by selecting it in Tower's sidebar.
Effective, Shared, and Local Config
On the top right of the view, three tabs represent different configuration levels:
- the General tab shows you the configuration as it's currently in effect
- the Shared Config tab shows the config values that are stored and versioned in the main repository
- the Local Config tab allows you to override some of the Shared values; these settings are not versioned with the repository and are only valid locally for you
The name value is used e.g. in Tower's sidebar. By default, it matches its path value.
The local path where the Submodule repository is located inside its super repository.
- Clean: Checked out at the committed revision; not containing any uncommitted local changes
- Dirty: Contains uncommitted local changes
- Uninitialized: Not yet properly initialized; can be done using the option
- Updated: Revision pointer was moved (but the move was not yet committed)
- Invalid: Configuration is invalid; you can try fixing this using the option
Checked Out Revision
The Submodule revision that is currently checked out in the parent project's working copy.
The Submodule revision that is currently committed in the parent repository. If this diverges from the "Checked Out Revision", this means you should either commit the moved pointer or use the "Update" feature to reset the checked out revision to the committed pointer.
The remote URL of the Submodule repository.
Local Submodule URLs (Per User)
By default, a Submodule's URL is saved in the ".gitmodules" file in your project's root directory. It's under version control like any other file and therefore is the same for every user. This means that a username should never be part of the URL.
If the Submodule requires a personal authentication (a unique username for each user or even a unique URL altogether), the URL can be overwritten in your local, user-specifig .git/config file that will not affect the global, checked-in URL. You can do this in the Local Config tab.
You can configure when a "Fetch" operation shall be executed in the Submodule: either "always" (i.e. always when you "Fetch" in the super repository), "on demand" (i.e. only when the Submodule tries to check out a commit it doesn't have, yet), or "never" (i.e. you must perform "Fetches" manually).
You can define which of the Submodule's modifications shall be shown in the super repository's Status. You can choose to be notified of all changes, only of changes that affect tracked files, only when the commit pointer was moved, or never.
As an advanced option, you can define how exactly an "update" operation shall be performed: with the "--checkout", the "--rebase", or the "--merge" flag.