Hi Stefan, I appreciate the effort to remove obstacles to the use of submodules! It looks like a custom tool is probably still our best option at this time, though we can always switch back to submodules later. On Wed, 2016-10-26 at 16:23 -0700, Stefan Beller wrote: > On Wed, Oct 26, 2016 at 4:07 PM, Matt McCutchen <matt@xxxxxxxxxxxxxxxxx> wrote: > > - We have to make separate commits and manage corresponding topic > > branches for the superproject and subprojects. > > Well yeah, that is how submodule work on a conceptual level. > While having multiple commits may seem like overhead, note > the subtle difference for these commits. One if deep down in the > stack patching one of the submodules, the other is a high level > commit advancing the submodule pointer. > > Note that the target audience of these two commit messages > might be vastly different, hence can be worded differently. > (The submodule describing how you fixed e.g. a memleak or race condition > and the superproject describes on why you needed to include that submodule, > e.g. because you switched your toplevel application to use threads.) I understand one can adhere to that philosophy, but I don't see the practical benefit of doing so in our case compared to using a "git subtree"-like approach and making a single commit. It would just be us looking at both commits. If we do upstream any of the library changes, we'll probably have to rework them anyway. > > - A diff of the superproject doesn't include the content of > > subprojects. > Although this is just Git, you probably also have a code review system that > would need that change as well. Indeed. We currently use Bitbucket. I'd be open to switching, though maybe not just for this. > Is there anything else besides these 3 points that encourages you to > switch away from submodules? Those 3 are the ongoing pain points I can think of. There are a few other drawbacks compared to "git subtree" that come up less often: 1b. On another project, I was working with a teammate who was new to version control and not very careful, who forgot to run "git submodule update" and ended up committing back the old submodule pointer. Thankfully, this hasn't happened yet on my current project. 4. I pushed several dangling submodule pointers before I learned I could set push.recurseSubmodules = check. This isn't the default; each developer has to do it manually. (In theory, I could put such things in a setup script for them to run if they trust me.) 5. Stashing changes to both the superproject and the subproject takes more steps. 6. I use multiple worktrees (with "git worktree") because of #5 and also so that I can run two versions of the application at the same time and compare the behavior. Using "git worktree" with submodules is officially unsupported, though I was able to get things working by manually editing some files. 7. We have to set up a repository for each subproject on our hosting service. Anyone who forks our application and modifies a subproject has to set up a subproject repository and carry a change to .gitmodules to point to their repository. If we use relative URLs in .gitmodules, it's even worse: anyone who forks our application has to set up repositories for all the subprojects, even if they don't modify them. Matt