Should "git submodule update" accepts --init?

Hi,

The command "git submodule update" accepts an "--init" flag to initialize an uninitialized submodules.

Shouldn't it also accept "--sync" flag in order to sync and unsync'd submodule?

Otherwise it seems like I'll have to do "git submodule update" twice in order to update an already initialized submodule whose upstream repo url has been updated in .gitmodules to point to somewhere new, like so:

$ cd superproject $ git pull $ git submodule update --init --recursive fatal: reference is not a tree: c21784553dcd15e1534773fe3177f39cbb93be65 Unable to checkout 'c21784553dcd15e1534773fe3177f39cbb93be65' in submodule path 'path/to/submodule' Failed to recurse into submodule path 'path/to/submodule' $ git submodule sync $ git submodule update --init --recursive

If the submodule update subcommand accepts the "--sync" flag then above can then be simplified to this:

$ cd superproject $ git pull $ git submodule update --init --sync --recursive

So the "--init" and "--sync" flags tells git to initialize an uninitialized submodule, and syncs any out-of-sync submodules.

nazri

Nazri Ramliy <ayiehere@gmail.com> writes:

I am not a heavy submodule user so what I think may not count, but I think the "upstream" changing the URL of the submodule should be a rare and notable event. Making it easy to automatically run "sync" without thinking would be a huge mistake---it will make it likely for users to blindly follow what the upstream has in .gitmodules without checking if the new URL is sensible.

Also doesn't "submodule sync" blindly overwrite URL, even the ones that you tweaked in your configuration to override to point at a mirror that is closer to you than the one suggested in .gitmodules? If that is the case, sucn a change to make it easier to run "sync" without thinking is doubly bad, I would think.

On Thu, May 11, 2017 at 2:42 PM, Junio C Hamano <gitster@pobox.com> wrote:

Yes that would be a mistake for the case when we don't trust upstream. But for the case that we do trust upstream, I would argue that we should always follow what upstream told us to use when it comes to getting the content of the submodule.

For such use cases I would suggest using url.<pattern>.insteadOf, instead of changing what submodule.<name>.url.

My recent use case that prompted this question (I just realized that I typo'ed the mail subject s/--init/--sync/) is this:

We are using git submodule for vendoring our Go dependencies. We've been using it since 2015 and it has been great for this role. There comes a time when we have to patch the vendored version so we do what is normally done - we fork the code at github and made a pull request. This pull request may get rejected, or accepted. For the latter case it may take some time for the acceptance to happen - upstream owner may be away, or there are some cosmetic changes needed etc, while on our side we need the changes in place for our build (and on developer machines) to succeed so that it can be used in production (after testing it in our staging). It is during this time that we want to switch the submodule url (upstream github repo) to point to another submodule url (our github repo)

Hmm after writing all of the above I wonder if we can't just use url.<pattern>.insteadOf to achieve this. But then url.<pattern>.insteadOf feels less official than submodule.name.<url> so that's another point to think about.

nazri