CODEWITHSUNDEEP
gitbitbucket
GnomeDePlume
GnomeDePlume

Reputation: 1642

How can I ensure that all submodule commits referenced by a git superproject are valid (and stay valid)?

As a developer I have a superproject that uses a submodule. I can configure git to ensure that commits to the superproject have valid submodule references at the time of pushing them (git config push.recurseSubmodule check).

Can I configure git/BitBucket to ensure that gitlinks referenced by my superproject will always exist in the submodule?

In particular, I am concerned about the following scenario:

I need to retain control over what is referenced in the superproject (I don't want to automatically follow a branch on the submodule).

Potential approaches:

  1. Is there any way with git or BitBucket to enforce that the superproject can only contain submodule gitlinks that are on the submodule master branch?
  2. Is it possible to enforce that any PR merges in the superproject only contain commits where the gitlinks resolve against the submodule master branch?
  3. ... or some better approach here that I'm not seeing at all?

Side note: I've attempted to go through the process to break the superproject, but it didn't work! I think that this is because the SHA of the feature branch on the remote is not immediately cleaned away (reflog default pruning strategy is to keep 90 days history).

Upvotes: 0

Views: 138

Answers (1)

jthill
jthill

Reputation: 60305

Just keep your own copy of the needed commits, keep a bitbucket fork or a local clone or whatever, with tags for the referenced commits.

As an academic exercise, if you were using Git and not bitbucket to do your merging, the checks would be like five lines of hook,

git rev-list ..MERGE_HEAD` | xargs -rn1 git ls-tree -rd \
| awk '$2=="commit" {print $3}' | sort -u

to show you every merged submodule commit, and

[[ `git for-each-ref --count=1 ---format=ok  --contains $commit \
        refs/remotes/origin/{master,stable}` = ok ]]

to check whether $commit is in origin's last-seen master or stable histories, so a minimum-viable-smoketest for what you're after would be

for commit in $(git rev-list ..MERGE_HEAD` | xargs -rn1 git ls-tree -rd \
                | awk '$2=="commit" {print $3}' | sort -u); do
        [[ `git for-each-ref --count=1 ---format=ok  --contains $commit \
                refs/remotes/origin/{master,stable}` = ok ]] || die "Commit $commit is not published"
done

push.recursesubmodules check does pretty much exactly this, only without the specific remote and tracking restrictions

A note:

Common practice I'm familiar with has been to distinguish administrative status by repo residence, the QA team tends to run an ~incoming~ repo to which devs or review teams push commit series for integration, and the production team likewise will have a repository for code pushed into production, and so on. That way each team can trust people they know personally and do any automated vetting of inbounds in the pre-receive. All publishing repos really should be running sanity-tests on inbounds, and things like the above would be good candidates.

Upvotes: 1

Related Questions