During development, we used a git branch on MRtrix3 to include all of the enhancements utilised in this project. However branches are mutable and guarantee of persistence is low.
There's a couple of options here:
If you want for the code here to be dynamically updated to be possible to execute using the "best" code available:
Leave the MRtrix3ukb branch in place until MRtrix version 3.1.0 is released
When that release happens, change code here to pull that new MRtrix version
Delete the ukbMRtrix3 branch
If instead, you want this repository to be an effectively immutable reference of what was actually executed in generation of the distributed data, then either:
Modify the code here such that instead of cloning a specific MRtrix3 branch, it points to the exact commit that the ukb branch currently points to; or
Delete the MRtrix3ukb branch, and then create instead a ukbtag on MRtrix3, that points to the same commit (unlike a branch, a tag is considered immutable)
I am in preference of 2.i. We don't expect people to be re-running this script on subjects already processed, and so we don't want to be dragging in unrelated code updates. Within point 2, 2.ii would result in creation of a new tag for all clones of the repository that does not represent an incremental update of the software as defined by semantic versioning. 2.i is only a minor change here, does not require MRtrix3 changes (and allows me to delete that branch), and the version of MRtrix3 used in generation of the data can be referenced as 3.0.3 plus relevant updates (see also #37).
During development, we used a git branch on MRtrix3 to include all of the enhancements utilised in this project. However branches are mutable and guarantee of persistence is low.
There's a couple of options here:
If you want for the code here to be dynamically updated to be possible to execute using the "best" code available:
ukb
branch in place until MRtrix version3.1.0
is releasedukb
MRtrix3 branchIf instead, you want this repository to be an effectively immutable reference of what was actually executed in generation of the distributed data, then either:
ukb
branch currently points to; orukb
branch, and then create instead aukb
tag on MRtrix3, that points to the same commit (unlike a branch, a tag is considered immutable)I am in preference of 2.i. We don't expect people to be re-running this script on subjects already processed, and so we don't want to be dragging in unrelated code updates. Within point 2, 2.ii would result in creation of a new tag for all clones of the repository that does not represent an incremental update of the software as defined by semantic versioning. 2.i is only a minor change here, does not require MRtrix3 changes (and allows me to delete that branch), and the version of MRtrix3 used in generation of the data can be referenced as
3.0.3
plus relevant updates (see also #37).