Skip to content

General Rules for Merging Data

Data should be BIDS valid when merged in. We strive to have only valid data on the main branch. There might be cases where this is not possible:

  • Data is missing in such a way that BIDS throws an error, but we cannot fix it
  • There is an error in the BIDS validator
  • There is missing metadata on the merge request that has been added in main: the data will be valid as soon as it is merged with main

Any of these cases should be documented on the merge request. In case of missing data issues this should also be clearly reported in the dataset README.

In the last case it is important to immediately confirm that data is indeed valid once merged in. Any remaining errors should be handled with priority.

Frequent merging of all open MRs is important

If the differences between the MR and the target branch (usually main) are large, the initialisation of the file diff takes long — particularly on large repos with many LFS files. This has been reported to the Git LFS team.

The difference between branches should be kept as minimal as possible — merge in regularly, as soon as possible.

Legacy conversion

To keep branch differences at minimum it is recommended to complete the full process (e.g. creating event files, additional annotations) for one pilot subject first — to figure out how all other subjects should look (what information is needed, etc.). After the first valid subject is merged in, this serves as a blueprint and helps avoid large branch differences.