Once you’ve done this, anyone cloning the repository will also get the submodule, at the same commit. These uncommitted changes represent the addition of the submodule to your repository, and you must commit & push them as you would do with any other change. In Mercurial, there will be a “.hgsub” file instead but the principle is the same. You’ll see in the file status view that a couple of entries have been staged: In this case you’ve just added the submodule, but it’s not actually committed yet. ‘…’), or incoming / outgoing changes (up/down arrow). Submodule entries can also have annotations to let you know if there are uncommitted changes in the submodule (ellipsis annotation, i.e. If you wanted to see more detail about the submodule, just double-click on it to open it in its own repository window, from which you can, if you like, make changes to it just like any other repository. This tells you that your submodule is located in dependencies/sub1 and is currently on the ‘master’ branch. Once the submodule has cloned, you’ll see it appear in the sidebar like this: You’ll then be prompted to provide a source URL to clone the contents from, and the path within the current repository that this submodule will reside. Adding a submodule to your projectĪdding a new submodule to your project is simple, just right-click on a blank area of the sidebar and select ‘New Submodule’ (or select it from the Repository menu). The most common reason for wanting to do this is that your project has dependencies on other code bases (libraries for example), and you want to track those from their original sources rather than duplicating the files within your own repository.įor the sake of brevity from here on I’ll use the term ‘submodule’ to mean ‘subrepository’ as well, unless I’m talking about a Mercurial-specific feature. The terms may be different, but they refer to the same concept that of nesting other repositories within the folder structure of your own repository. You can also change the commit that is checked out in each submodule by performing a checkout in the submodule repository and then committing the change in the parent repository.Using submodules and subrepositories By Steve on February 1, 2012Ī headline feature of SourceTree 1.3 is the support for submodules (in Git) and subrepositories (in Mercurial). This is common when you are experimenting with different checked out branches or tags in the submodule and you want to restore it back to the commit tracked by the parent repository. ![]() ![]() Performing a submodule update is also useful when you want to restore your submodule’s repository to the current commit tracked by the parent repository. You would then fetch the latest changes in the submodule’s Git repository and perform a submodule update to check out the current revision referenced in the parent repository. You commonly perform this task after you pull a change in the parent repository that updates the revision checked out in the submodule. ![]() Performing a submodule update checks out that specific revision in the submodule’s Git repository. In this case the Git parent repository tracks the commit that should be checked out in each configured submodule. Alternatively to the tracking of a branch, you can also control which commit of the submodule should be used.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |