Missing submodule command - git submodule update --recursive --remote

[laurinkeithdavis]

Am I crazy or is this missing as an option?

git submodule update --recursive --remote

I don't understand why "Update all submodules" does this instead?

git submodule update --init --recursive

That command does not pull from the remote.

[laurinkeithdavis]

FYI, know I can do that with a script and I have, but seems like this is a common use, while --init is only for when a repo is first checked out.

[laurinkeithdavis]

But it does not work, these are not the same commands and do not do the same thing. When I do "Update all submodules" (which is git submodule update --recursive --remote), it does not update the submodules to the most recent commit in the branch they are in, but if I do git submodule update --recursive --remote from the command line it does. I've tested this multiple times. "Update all submodules" appears to be pulling down the changes, but when I switch to that submodule, the new commits are not there and the current revision has not changed.

Not knowing these commands terribly well, maybe the issue is that the "Update all submodules" command does not include --remote. Yea, I bet that is what I am trying to get at (sorry, was confused about --init):

https://git-scm.com/docs/git-submodule#Documentation/git-submodule.txt---remote

I'll test this now.

[vbjay]

That's because update all submodules isnt set to do that. It is set to make sure that when you move your parent repo HEAD that the sub modules sync up to be where that commit points in the sub module.

[laurinkeithdavis]

Well, but that's what I am saying, the command we need is missing. I don't even see how that is useful doing an update without --remote is useful, as that means I have to switch to each submodule and fetch to update all that repo to the current remote head.

The current command is definitely not useful to us, as we want all submodules to stay current with their remote head. That's why this discussion was titled "missing command". :)

Can you explain the purpose of this?

It is set to make sure that when you move your parent repo HEAD that the sub modules sync up to be where that commit points in the sub module.

How do I set or change the "parent repo HEAD" for a submodule? I guess that has to be done manually?

[vbjay]

Making this change

Parent repo already staged

So now I have a just a test commit that has a sub module change.

Let's create a branch here

Do you see how update submodule runs and makes sure all my submodules are at x point based on the commit in the GE repo? That command does fetch missing commits if needed as seen here

Niow in the submodule I check out

and then go to GE repo and...

If you want to do stuff in the submodule like check out latestfrom x branch. Do so the parent repo will reflect that status but you manage the submodules like so.

If you want to sync up changes in a submodule with latest then do a fetch/pull in that submodule. Update all submodules is geared to making sure you can start your work with all submodules pointed to a specific commit when you bounce like when I check out master and it moves the submodule back. to my just testing commit

[vbjay]

As long as you follow master being the correct branch to sync off... this script works

-c "git submodule foreach git checkout master && 
git submodule foreach git pull upstream master && 
git submodule foreach git push origin master && 
git checkout master && 
git pull upstream master && 
git push origin master &&
git submodule update --init --recursive"

[laurinkeithdavis]

Wow, thanks for all that info, that must have taken you a while.

If you want to sync up changes in a submodule with latest then do a fetch/pull in that submodule.

Ok, that's what I thought you were getting at, and yes, we don't want to do that, we want the submodule to stay current with the head of its remote.

If you want to do stuff in the submodule like check out latestfrom x branch. Do so the parent repo will reflect that status but you manage the submodules like so.

Tried that, but still does not fetch from the remote. Maybe I'm missing something here.

As long as you follow master being the correct branch to sync off... this script works

Not sure why we would need to do all of that, as git submodule update --recursive --remote as the script seems to do all that we need. We don't need the local master of the submodules to be updated, we just need the checked-out revision to be the most recent on the remote. Anyway, I'll try your script and compare the difference. Again, thanks.

[vbjay]

I did that to get my master in my forks synced up to my remotes so yes it does more. If you want to add the pr that adds the menu option, then some points:

• Synchronize menu does something else and is not what you want.
• I would ask @RussKie what the menu should say.
• The complexity issue with a menu option that does what you ask is that what if git config is not pointed to a specific branch as the source of truth to sync latest changes? Does it just do a defacto master or what?

[vbjay]

For now I would add a script that does that and play with it. I would also create a submodule that doesn't have branch filled in and set up the remotes and see what that does. Note the research in your pr showing the menu behaves like this in these states.

[eng-marani]

I had the same issue. I know is not a typical workflow, but sometimes you need a submodule to always point to the "head" revision of the selected branch as configured, and there is not an asy way other than use a git script or go manually on each submodule one by one fetching/merging from the head, than sync the main repository again recursively

[vbjay]

That's correct. As it should be. It would be a nightmare if it was the other way. If I move my head in my super repo to a commit, as expected I expect the sub repo to be checked out at the commit the super repo points to. Look at the .git file you commit when you do move the submodule to a new commit. It is just a sha. We on purpose do not have the functionality you are asking for. You can develop a script like mine. Mine does more than just sync up from remote and I could have used inputs in the script to select remotes and branch names.

What happens when you use your command you want to run and the submodule is in a headless state? Which is most of the time after being put in the right state after update init.

If you want the command add it to scripts and test it out. Test with both headless state and a branch checked out.