This means that even though the submodule is pointing to the correct ref/code revision, but it isn’t setup to update from or commit to a specific head (branch). (thanks Shawn) Submodules require extra steps when committingĪfter initialization, your submodule will initially be in a “detached head” state. This step will get all if your submodules setup, pointing to the proper refs, etc. From inside the newly cloned repo (at the top level), you have to initialize and update the submodules: With Git submodules, an additional step is required after a git clone. With a standard SVN checkout, all of your externals get populated and are ready to go right away. Submodules require extra steps when cloning while the other includes design docs, mockups, etc. One has just the code, README, CHANGELOG, etc. This means you’ll want to keep your code repositories lean and mean – you don’t want deep URL paths or a bunch of historical design documents and other things in there that would be considered cruft when the repo is used as a library for another project.īecause of this, we’re often maintaining two Git repos for each project. With SVN you can make your external point to a subdirectory of a project (this is how you’d choose trunk vs tags/1.0.2, etc.), with Git the submodule will always be the entire project. The submodule will be the entire Git repo With Git’s submodules, you can still bring in another codebase into your project but the mechanics of it are a bit different. You might be pulling in changes on each “svn up” that you don’t want. Primarily you can run into multiple people updating or needing to work on an external at the same time (and SVN doesn’t well support a branch-driven development model). That doesn’t mean there aren’t some challenges there. Like I said, it’s something you can get away with. If you follow a good trunk/branches/tags model within your externals, you can get away with this without too much trouble you primarily point the external to the latest stable tag, but switch the pointer to trunk when active development is needed. With SVN externals, the included externals are automatically updated to the latest version on every update (unless you –exclude-submodules). Often times active development would be happening on a specific project and within one or more of the externals within the project (to support a new feature, etc.). To support this approach we previously made extensive use of SVN externals in our projects.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |