[Bro-Dev] Git merge and submodules

[Jonathan Siwek]

> Gregor and I talked yesterday about adding a simple script like
> "fix-submodules" that would do whatever is necessary to get the
> submodules into the right state (which probably is just such a
> recursive update; but Gregor, didn't we have a second thing the
> script could do as well?). So, after a merge one would just run that
> and be good.

Yeah, I think doing a recursive update of submodules is the right thing to do after merging with another branch.

But the other case (which is probably less common) is that someone may be doing work on the submodule repositories.  The submodule update command for them does the wrong thing.  They need to either

1) Ignore submodule changes that `git status` (i.e. don't commit submodule pointers), either with a gitconfig option or just by cautiously not adding submodule changes to commits.

2) Go ahead w/ committing submodule pointer changes

In either case, the repo maintainer will make sure every submodule points to the most recent master commit after a branch is merged.

Do you have an opinion for which convention we should follow?

Since the same thing happens in the end, maybe it's fine to just leave it to developer preference (as long as they try to avoid spamming the commit log with purely "update submodule" type commits if they choose #2).

> Another script which I think would be useful is something like
> "update-submodules" that moves all submodules to their most recent
> version (e.g., if we're in master, checks out all the other master
> version and commits the update).

Sounds useful, but mostly for use by repo maintainers, right?

But the name might be confusing because it actually doesn't involve the submodule update command.

- Jon