![]() ![]() I think it feels this way because git modules are still fundamentally weird. Sometimes all of this feels a bit wonky to me. If we’re using gitflow, we won’t be making any changes outside of a feature branch anyway, so if we’re using a function like the above one, we shouldn’t ever run into a situation where we’ve blown away changes we’ve made in our submodule. Git submodule foreach 'git checkout -b'$1 I’ve already git status and git push aliased to gs and gp respectively, so gc is a good name for this function: I’ll make a bash function to support this. This is probably something that I should just always do from now on. This isn’t a problem if you know that you’ve got submodules, but its a little annoying and surprising to see a build error when you don’t realize that the project has submodules.Ī remedy here is to use the -recursive flag on the git clone command. The first thing that’s annoying about git submodules, in my opinion, is that when you check out a project, you can’t get it to build without initializing and updating your submodules. ![]() Managing git submodule complexity Working around init and update The next section is about some of the complexities of git submodules and the techniques the git folks recommend for managing these complexities. This additional complexity may be worth it if you’re trying to work on shared code and project code simultaneously and if there are methods of managing this complexity in a way that a) keeps us moving quickly and b) helps us avoids costly mistakes. There’s additional complexity that comes along with using git submodules, and this complexity isn’t worth it if there are simpler ways of sharing code. So, if you’re using git submodules merely as a way of sharing code, that’s probably misguided, as it’s a use case that git submodules weren’t designed to handle. Otherwise you would probably instead be using a simpler dependency management system (such as Maven or Rubygems). It’s quite likely that if you’re using submodules, you’re doing so because you really want to work on the code in the submodule at the same time as you’re working on the code in the main project (or across several submodules). If you’re not trying to change the shared code along with the consumer of that code, there are better options for sharing your code. Its more accurate to say that git submodules are useful when you want to share code that you also need change along with the consumer of that code. As the above example from the docs suggest, that’s not entirely true. I used to think submodules were designed for the purpose of sharing code. It is not uncommon at all when working on any kind of larger-scale project with Git to find yourself wanting to share code between multiple different repositories – whether it be some core system among multiple different products built on top of that system, or perhaps a shared utility library between projects.Īt first glance, Git submodules seem to be the perfect answer for this Interestingly, this is very different from what we might call the “naive perceived purpose” of git submodules, which is well captured by the opening paragraph of the aforementioned article arguing against git submodules: The issue with vendoring the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. Instead of writing your own Atom-generating code, you decide to use a library. Suppose you’re developing a web site and creating Atom feeds. The docs actually provide a very helpful example to answer this question: ![]() What follows are some more nuanced thoughts on how and when git submodules can be used effectively. A part of the reason I had this simplistic view was because of an article called “Why your Company Shouldn’t use Git Submodules.” I took a second look at this article recently and I read the docs on git submodules. This was naive, as most choices in software development are about tradeoffs. I used to think git submodules were categorically evil. ![]()
0 Comments
Leave a Reply. |