1

I'm helping to maintain an open-source project on which we've run into frequent problems with our sub-modules breaking our historical builds because they force push to their receptive git repos. I realize that there could be valid reason why you may be required to force push to a public repository (for example regulatory or legal reasons to remove code from your codebase and history). What I'm wondering is, is there anything we can do while making use of git submodules to mitigate the risk that we're affected by future force pushes?

I've proposed that we track submodules by branch, especially where these submodules make use of release branching best practices, but it seems this may not help. Even when tracking a branch git hashes are still committed to our repo, and code potentially be removed from our submodule's remote repo if they re-write their commit history. Am I right in assuming this means tracking a branch will not offer us any extra protection against future force pushes? Are there any other techniques people can use to avoid this problem?

References, submodule update not making use of branching: https://github.com/apache/incubator-mxnet/pull/13322 submodule update tracking a branch (note both have current hash committed): https://github.com/apache/incubator-mxnet/pull/13378

Kellen
  • 621
  • 1
  • 5
  • 15

1 Answers1

1

Tracking a branch or not, a submodule is first a recorded SHA1 (gitlink) in the parent repo.

Before doing any git submodule update --remote --recursive (which would update those SHA1 with new ones, potentially being ones forced pushed) you need to keep track of those SHA1 before update.

Then you update and check if the new SHA1 represents forced pushes

git rev-list oldrev ^newrev
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250