Adding a pushurl to git submodule

Question

I want to add a project into my repo as a submodule. For example, I want to add https://aur.archlinux.org/packages/gnome-keyring-query/ as a submodule. I have added it and looks like it's working, i.e. git submodule update --recursive works.

Now I have added a new file (i.e. Makefile) to gnome-keyring-query and I want to keep that submodule into my repo with that Makefile. Therefore, I have added a pushurl (my repository url) to the .gitmodule file. But it does not work, I mean, I can't push. Then I tried adding the pushurl to .git/modules/...path.../gnome-keyring-query/config file. Still it does not work.

Any idea?

Answer 1

The submodule system allows making a separate repository appear in a subfolder of your own, but it doesn't go any further. They are still separate repositories as far as git basic functionality is concerned.

You can commit to either the parent repo (as if it didn't have the submodule), or the child repo (as if it didn't have the parent repo). Same with pushing: you have one remote (or a set of remotes) for the parent, and another one for the submodule.

I can think of a couple of solutions for your issue:

• either add a Makefile to your parent project, and commit it normally, but adjust the Makefile target commands so that it operates on the gnome-keyring-query submodule, i.e. you might add target names like make keyring-this, make keyring-that.
• or make a fork of the submodule repo, and push your Makefile commit to that fork.

The first approach is easy and straightforward, but it doesn't let you modify the submodule source code or configure it a lot besides what is provided by the authors. You essentially gonna have the submodule remote as read-only.

The 2nd approach is more flexible, but it certainly increases the cognitive load (you have to keep track of 3 branches: your repo, submodule-fork and submodule-upstream (origin) instead of 1), which is one of the reasons of why submodules are infamous, and why some alternatives like git subtree exist.

P.S. In many cases I prefer to avoid submodules in favor of package managers or even vendoring (copy pasting the source and/or binaries), which tends to be a lesser burden, especially if you are not planning to use submodules at scale (for managing a significant number of dependencies).