Exercise Review 3

Creating Backups and Sharing DataLad Datasets

Michał Szczepanik

m.szczepanik@fz-juelich.de

Research Center Juelich

Ole Bialas

bialas@uni-bonn.de

University of Bonn

August 19, 2025

Using a Bare Git Repository as Push Target

• bare == no worktree
  • contents of .git directly in the directory
  • when shared pushes can’t break the worktree
  • suited for storing on a server ¹
• with git-annex on the machine, can store git+annex
• good default for Git & git-annex aware services

Demo: git init --bare ~/penguins_backup

1. https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server

What Contents Are Actually being pushed?

• Any git repository (local or online) can be added as a dataset sibling
• The first push initializes the repository’s annex ID, the second push actually tranfers the files
• datalad push acts on the contents you already got
  • to transfer specific files, use datalad get first

• Sibling demo: datalad siblings add --name backup --url ~/penguins_backup

• push demo: tree -d ~/penguins_backup datalad push --to backup datalad push --to backup tree -d ~/penguins_backup

• Note that DataLad will only push the files that are present in the current repository. For files that are not present, we have to use datalad get first

Using non-Git-aware Storage Services

• git-annex has special remotes that implement various strorage services (git annex initremote)

• you can have multiple special remotes with fine-grained configuration:
  • preferred content (think:which files should be stored?)
  • numcopies (think: how many copies should be kept?)

DataLad Supported Services

• DataLad supports all services that are supported by git-annex

• DataLad supports additional services via dedicated extensions (check the handbook)