0

On my project, we are using git submodules to manage some plugins. Both our core project and the submodules are being developed on in parallel. As a result, it doesn't work well for us that we have to update the SHA of the submodule in the core project every time the submodule moves forward (and have to resolve conflicts on that SHA between different developers, etc).

We would like to tell it to track a branch and let that be that. But it appears that submodule branch tracking makes it easier to update the submodule, but does nothing to alleviate our issue of having the super project point to a particular SHA instead of a branch.

Anybody have any suggestions for us?

Eric
  • 1,414
  • 3
  • 16
  • 35
  • 2
    It sounds like you're trying to use Git to manage dependencies. It's not a very good at that. You might need a real dependency manager. Or if you find you have to track the absolute latest commit, those two repositories may be better as one. – Schwern Jun 21 '17 at 19:30
  • 2
    I don't believe git can do what you're wanting. A commit represents a specific version of the code, and allowing a submodule to specify a ref would violate that - so that a commit works today, but due to a ref in a submodule's repo moving, the same commit in my repo stops working tomorrow? And you could say the same is true of dependency managers with version ranges, but at least you have tools like semver to limit the slipperiness. (And even then you still have tools like shrinkwrap for production versions.) – Mark Adelsberger Jun 21 '17 at 19:41
  • See https://stackoverflow.com/questions/9189575/git-submodule-tracking-latest – nos Jun 21 '17 at 19:44
  • @Schwern We can't put the plugin repositories inside our core because they are managed by an independent team and doing so would make it difficult to update to their latest changes (which we do always want). – Eric Jun 21 '17 at 19:58
  • @MarkAdelsberger I understand that for many use cases, what you're suggesting would be very desirable. But honestly *that* sounds like what a person would want a dependency manager for. In my use case I really do want the plugin submodules to move forward. If they stop working with the latest core, we have an issue that we need to track down. – Eric Jun 21 '17 at 20:00
  • @nos Thanks for the help, but the answer to the question you linked suggests the submodule branch tracking that I mentioned above. It makes it easier to update the submodule but does nothing to alleviate our issue of having the super project point to a particular SHA for each submodule. – Eric Jun 21 '17 at 20:01
  • Well, you can say you'd think that dependency managers and git submodules should swap what they're good at if you like, but the fact remains they're good at what they're good at. What you want is what you get from a dependency manager with -SNAPSHOT version conventions or broadly-set version ranges. And git doesn't have those things. These are industry norms because a lot of people disagree with your intuition about which job should require a dependency manager. So dislike it if you want, but if you want to make it work, use the tools that are good at making it work. – Mark Adelsberger Jun 21 '17 at 20:09
  • @Eric You can write a script that updates the submodules periodically, runs it through CI, and pushes that change up so the devs can see it. You could make that part of your build process, but then you're actively developing against a moving dev release dependency. But I still say the answer is a dependency manager hooked into your build process. Many will get their dependencies from Git. – Schwern Jun 21 '17 at 20:22

2 Answers2

1

One possible alternative is to use a git subtree rather than a submodule.

Having used one I'm not sure that I'd recommend it as a long term solution but https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree and https://legacy-developer.atlassian.com/blog/2015/05/the-power-of-git-subtree give a reasonable tour of how it works and should help you decide if that's a better workflow for your specific needs.

Jonah
  • 17,918
  • 1
  • 43
  • 70
  • Thanks, @Jonah! I'm definitely going to experiment with it. I also figured out a workaround for our problem that I will also post as an answer in case it's helpful to anyone. – Eric Jun 22 '17 at 00:11
0

As others have noted, git submodules aren't designed for what our project is doing. But I found a way to effect what we want ... posted here in case it's useful to anyone:

  • We do not commit our local changes to the submodule index to avoid the extra workflow step and the hassle of frequent merge conflicts on those indices which are not handled well by git GUIs.
  • We then marked the submodule folders as "assume unchanged", which hides local changes from us such that we can effectively ignore as that index changes

So, that gives us what we want ... a submodule that allows new users to recursively clone all associated plugins and do bulk operations via git submodule <command>, but without tripping over the fixed commit SHA that we didn't want.

Eric
  • 1,414
  • 3
  • 16
  • 35