Skip to content

Conversation

@joshmoore
Copy link
Member

The issue we saw with ome/omero-scripts#12 was:

  • PR 12 opened and was merged properly.
  • PR 12 was merged.
  • No other PRs were open.
  • Therefore, the sha1 of the module wasn't changed.

In other words, the modification tracking that was
in place looked solely for PR merges but didn't
take into account whether or not the submodule
pointer needed to be bumped. Rather than worry about
trying to properly track that, this commit removes
the modification check. The next step is to
guarantee that the submodule will be updated
to the appropriate base.

The issue we saw with ome/omero-scripts#12 was:

 * PR 12 opened and was merged properly.
 * PR 12 was merged.
 * No other PRs were open.
 * Therefore, the sha1 of the module wasn't changed.

In other words, the modification tracking that was
in place looked solely for PR merges but didn't
take into account whether or not the submodule
pointer needed to be bumped. Rather than worry about
trying to properly track that, this commit removes
the modification check. The next step is to
guarantee that the submodule will be updated
to the appropriate base.
Pass the base to all submodules in order
to fast-forward the pointer. If a ff is
not possible, the build will fail. Also,
if the submodule branch names do not
match that of the main repo, the build
will fail.
@sbesson sbesson mentioned this pull request Nov 27, 2012
@joshmoore
Copy link
Member Author

closing in favor of 14.

@joshmoore joshmoore closed this Nov 27, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant