The parent repository is now pretty slim it contains the. The commit points to the current version of HEAD in the checked out submodule, which as can be seen here is e9ed329101157ce9be5dc1c2639096bd82d3fa05. This points to a commit, unlike the tree-or- blob that we've seen before. Instead of a simple mode 100644, which is used for storing a file with rw-r-r- permissions, 160000 is used instead. (master) $ (cd BigJobbies git rev-parse HEAD) (master) $ git commit -m "Added BigJobbies submodule" If we add the contents, commit, and then look at the tree, we'll get our answer: However, in the git status, it shows up as a file. gitmodules file and created a BigJobbies directory, corresponding to the BigJobbies cloned data. Initialized empty Git repository in parent/.git/ For example, if you wanted to add the BigJobbies project earlier as a submodule, you could do: To add a submodule to an existing project, run git submodule add to define a local directory corresponding to the remote Git project's contents. The submodule (sub repository) can evolve at its own pace, with its own checkouts, and the parent can refer to it by a fixed hash. Git submodules works these two concepts together, by treating a submodule as a logically checked out directory in another repository, but referring it to it by a pointer rather than a full checkout. bigjobbies file suggested before.) Since they are referenced by hash, as long as you can acquire the hash then you will be able to restore the asset. However, tags can change (although they're not supposed to) and conventions can be circumvented.Īnother way to do it is to store a pointer to the assets. If you're storing these as separate git repositories, how do you ensure that they are kept in sync with each other? Well, you could use tags and rely on convention to ensure that you can acquire the same version of the assets. The history of one will therefore not affect history of another. The obvious solution to this problem is to store source code (and other compressible assets) in one Git repository, and then store large media assets (sound effects, in-movie videos etc.) in another Git repository. Files above 512Mb (by default) are stored without any delta compressions to previous versions (though they are deflated at storage time). Git also has a configuration variable, core.bigFileThreshold, which can be used to set the limit at which files are stored as-is without performing any delta comparisons. Typically, large binary assets (such as audio files, movies or even images if they've been saved in a compressed format) share little of the same binary data under the covers. Although Git provides a good delta encoding for existing files, these tend to only work if the binary data is relatively similar. The reason one might want to do that is to avoid a checkout from the server taking a significant period of time, or taking up additional space once the clone has been made. In the previous post, I wrote about a tounge-in-cheek extension called git bigjobbies the purposes of which was to store large binaries in a repository without them being part of the main branch (and thus, not appearing in the history). You can subscribe to the feed if you want to receive new instalments automatically. This week's Git Tip of the Week is about git submodules.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |