-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split the parameter files into an independent repo? #13
Comments
This is a possible use case for git submodule, https://git-scm.com/book/en/v2/Git-Tools-Submodules. The prminput directory would be its own repository (e.g. japan-prminput-prexcrex) which is included as a submodule at Parity/prminput for installations. That submodule can point to the repository of the current commonly used experiment (i.e. prex/crex now). Export of the current content of prminput, with history, into a new repository is possible (if not trivial). |
I was wondering about using a submodule, but thought I understood that it would require an extra step for users to checkout a working copy. I didn't read enough to understand the trade-offs. Although, if we just had a separate repo (not a submodule) a user still needs to do a separate checkouot and then needs to set up their directories correctly, so a submodule is likely better than a fully independent repo. |
The first level submodule is transparent upon checkout. Nested submodules is a pain. Submodules are pinned at a specific commit hash of the included repository. E.g. I think it would go something like this: Risks: changes in submodule directories are not ever pushed anywhere since git diff in japan/ doesn't show them. |
Following commands to extract Parity/prminput into https://github.com/JeffersonLab/japan-prminput-prexcrex as a proof of concept (probably doesn't need all branches)
|
Proof of concept on submodule at https://github.com/JeffersonLab/japan/tree/submodule-prminput. |
…pilation Merges the updates that were committed to the original "japan" repository to support compilation on macOS and compilation with llvm/clang on any system.
For maintainability reasons, it may be a good idea to import all the parameter files into a separate repo, and than possibly include that as a dependency.
If we don't include that as a dependency, we should leave a few example parameter files in this one.
We should then make sure there's a command line argument to define the parameter file path. Perhaps if the "config" argument contains a path, it would be included as the first search path for all other parameter files?
Rationale: the parameter files change much more often than the actual source code, and so their changes can clutter the real source file changes. Also, we could easily make branches or forks representing different experiments (PREX vs. MOLLER, for example).
The text was updated successfully, but these errors were encountered: