Handling submodule updates

Development Team
1

I talked to some people who are having problems in checking out old versions of our code base. The problem is that they because commits in the submodules vanished from the server. To show this problem try to checkout the branch “old/next-21 in my repository: GitHub - lucasdemarchi/ardupilot at old/next-21” old/next-19 in my repository: https://github.com/lucasdemarchi/ardupilot/tree/old/next-19. If you succeed, it’s just because you had the git objects cached in your computer. If you try to clone again it will fail with:

Fetched in submodule path ‘modules/mavlink’, but it did not contain c47a4e6e1d008baa7af20818906b8275df49694d.

For my own use case of old commits, I just update the submodule, particularly because the problem was in the mavlink repository. However this may not always be the solution.

One could argue that people following development should stay close to master. But this is only part of the issue. It’s completely possible that in future we want to go back and test some thing in an old commit from the repository. This won’t be possible. And people will continue to suffer when they are checked out in an old commit (sometimes not so old for what matters).

I think we need to fix this problem. We have some options:

  • Never force push to the repository
  • When a rebase or force push is needed, push a branch or tag to make sure the state of the submodule is kept in the server

What do you think?

2

Just fixed the link to the branch I mentioned above.

3

I agree that this is a problem. My personal preference is leaving master alone and when in need to diverge from upstream create a ardupilot branch. That branch can be force pushed if needed, but a tag needs to be created at that time.

That’s just my personal preference of handling things, any way that leaves a reference to the old commits is fine to me.

4

When a rebase or force push is needed, push a branch or tag to make sure the state of the submodule is kept in the server.

I agree with that. That might be necessary when we have pending changes on the upstream repository that we want to use in our submodule. That’s the case with Waf. By the way, this rule invalidates the first one :slight_smile: hehe

I’d also say that if upstream uses some versioning system for the tag, try to name your tag so that it’s easy to know which version that point is based. For example, if our changes are on top of version denoted by tag v1.0.2, and we need to force push or rebase, then we create a tag in our fork like v1.0.2-<foo>. Where <foo> contents might be a sub-version or even a short string.

Best,
Gustavo Sousa