This is because you type git add subm to complete to git add submodule, but it auto-completes to git add submodule/ - note the trailing slash. If you use the command line it is easy to screw up your repository with git-add. This is not an issue for you, but for others using your code they will have to remember or be told to perform this step before compiling/running/testing your code. The initial pull of a git repo with submodules requires an additional step with "git submodule init". This may not be an actual downside if you actually want to pin a stable version, I was working with code that was WIP. This is because git submodules, unlike svn:externals, are pinned to a particular commit id. In order to keep up to date with the library repository, I had to perform a new commit to update the submodule git hash "pointer". I used git-submodule and git-svn and it worked reasonably well. The library is hosted in a subversion repository on sourceforge. I've used git to stitch together my own github hosted project and an external UI library that I wanted to use. I think that 'solution' is more trouble than it is worth. Neither system would automatically see branches you make in the other. If you try to run SVN & Git in the same directory, you make it very hard to use branching in either system, because SVN does branching by copying file directories while Git tracks pointers. Your shared scripts can be handled as another independent branch in your main directory which your external partners can pull from and push to as a remote branch. This makes it easy to send changes back to the external projects and is a perfectly acceptable use of branches in Git. This requires some discipline: if you make any changes to the external projects in your main repo, they must be made in the branch and then merged into the master and you never want to merge into the project branches. Set up each project as a remote branch in your main repo and merge from each of them into your master (integration) branch that also contains your core files. I think of this as a good way to include project dependencies, but it wouldn't work so well with shared files. This makes it easy to update the main project from the external projects, but complicated to send changes back to the external projects. Using subtree merge to bring your external projects into separate subdirectories in your main repo that includes your core files. There are two possibilities that keep the sub-projects as independent git repos that you pull from into your main (integration) repo: I imagine if I worked on larger projects with more submodules, I'd see it as a more beneficial tradeoff. Once you've set them up, working on the whole project requires adding additional parameters to almost every command and the syntax isn't completely regular. I haven't found submodules to be particularly useful on the (small) projects I've worked on. Still studying setting up 'remote branches' but other ideas are still welcome. (Hope this is clear and useful to others.) Being a web app, it is vital that all my pages link internally to a folder within them, and that testing and updates be done directly within that folder. Subtree-merging (introduced to me by Paul, below) will not do: It is difficult to update the source from within the project it is merged into, and that source must reside outside of the 'root' folder of the project.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |