If you clone an existing repository containing one or more submodules via Repository|Clone, make sure the option Include Submodules is selected, so that all first-level submodules are automatically initialized and updated. Without this option, you may initialize the submodules later by hand via Remote|Submodule|Initialize. Just Only performing the initialization itself will leave the submodule directory empty. For a fully functional submodule, you'll also need to do a pull on it, as described in Updating Submodules.
Submodules are showing up in the Repositories as well as the Files view. Submodule operations (from the parent repository perspective) will be performed in the Files view. 'Normal' Git operations on the submodule repository itself will be performed in the Repositories view.
To add a new submodule to a repository"ignore" a not-yet initialized submodule which you are not interested in, invoke Remote|Submodule|Add on the repository in the Repositories view and follow the dialog instructions.Deactivate. This will make the submodule vanish from the Files view unless View|Show Ignored Files is selected. Technically,
submodule.<name>.active=false will be set in the parent repository
To remove a submodule from the working tree, select the submodule in the Files view, invoke Remote|Submodule|Deinit. After deiniting you will probably want to Deactivate it, too.
To add a new submodule to a repository, invoke Remote|Submodule|Add on the repository in the Repositories view and follow the dialog instructions.
To remove a submodule from the repository, select the submodule in the Files view, invoke Remote|Submodule|Unregister, and then commit your changes. After the submodule is unregistered, you may delete the submodule directory.
Select the submodule in the Repositories view and invoke Remote|Pull. On the Pull dialog that shows up, check either the Rebase or the Merge option. Then, after the After the pull, the submodule will have a different appearance in the Repositories view if new commits have been fetched and a rebase or merge has been performed. This different appearance indicates that the submodule has changed and that you need to commit the change in the outer repository.
Open the repository settings via Repository|Settings, and on in the Pull tab section, enable Update registered submodules, so that SmartGit automatically updates all registered submodules when pulling on the outer repository. Additionally, you may also enable And initialize new submodules; with this, SmartGit will update not only registered submodules when pulling, but also uninitialized submodules, after having initialized them. The aforementioned aforementioned Update option will only fetch commits as needed, i.e. when a commit is referenced by the outer repository as the current state of the submodule. If you want to fetch all new commits instead, enable the option Always fetch new commits, tags and branches from submodule. Note that when you do a pull on the outer repository, you need to pull with subsequent rebase or merge, otherwise new submodule commits will only be fetched, without changing the submodule state (i.e. the commit the submodule is currently pointing at).
Submodule States and Transitions
The submodule has not yet been initialized.
|As Index||The submodule is correctly initialized and pointing to the same commit as registered in the parent repository's HEAD and Index.|
The submodule has been scheduled for addition in the parent repository.
The submodule has been scheduled for removal in the parent repository.
The submodule points to a different commit than registered in the parent repository's Index. This is usually the result after e.g. you've done a commit in the submodule repository.
The submodule is in conflicting state where it's unclear to which commit it should point.
The nested Git repository is not properly linked as submodule.
|Missing||Might happen if initializing a submodule has failed, e.g. after cancelling the credentials dialog. Use Initialize to initialize/fetch again.|