Some of the subdirectories in the ACME code contain code that was brought in from another repository.  List them all.

There are two ways to bring in code from one git repo to another: subtree and submodule.   ACME uses both and our procedures are described in Sharing External Code using Git Subtree and Sharing External Code using Git Submodules.    Any source brought in as an external must be independently buildable and testable in that external.

Subtrees

...

Terms

• external any subdirectory in ACME whose entire content is from another repository
• upstream master  the repository everyone is sending their changes to.  Only one so that everyone pulling from the same source is working with all the same changes.   The source of an external.
• submodule  a link that points to another git repository.  See Sharing External Code using Git Submodules  or submodules vs. subtrees
• subtree a set of files and commits from another git repo, brought in to your repo.  See Sharing External Code using Git Subtree
• monorepo multiple projects, related or not, in the same repo.

ACME Rules for new externals

1. The group needing the external can decide on the method on inclusion.  A POC for the upstream master must be identified.
2. The upstream master for the external must be build-able and testable on its own.
3. For submodules, the linked repo must be readable by all ACME developers.  If the upstream master can not be made readable, a clone must be maintained in ACME-Climate github and ACME then links to that clone

Development in externals

In general there several ways to develop with external code in ACME

• strict 1-way:  all development is merged to the upstream master first and flows down to ACME.  No exceptions.
• mostly 1-way:  prefer strict 1-way but some exceptions can be made for emergency fixes
• 2-way:  developers can make changes in ACME or the upstream master.  POC keeps them in sync.

More specific instructions for externals are below

Table of Externals currently in ACME