DATALAD-CLONE(1)
π NAME π
datalad clone β bestie, this is how you obtain a dataset (a copy!) from a URL or a local directory β¨
β¨ SYNOPSIS β¨
datalad clone [-h] [-d DATASET] [-D DESCRIPTION] [--reckless
[auto|ephemeral|shared-...]] [--version] SOURCE [PATH] ...
π¦ DESCRIPTION π¦
okay so the whole point of this command: you get a brand-new clone (copy) of a dataset and it lands in a directory that either doesn't exist yet or is empty. That's it, that's the vibe π«Ά
Real talk though β CLONE is a strict subset of what install can do. Lowkey by design. You can only grab a single dataset, and it will not immediately recursively install subdatasets for you. BUT (and this is the iconic part) once a (super)dataset is installed via CLONE, you can get any content β including subdatasets β with a follow-up get command. iykyk π
So what makes this different from just raw-dogging a plain git clone call? Four things, and I'm gonna list them because they ate:
- it automatically initializes a dataset annex (pure Git repositories are equally supported, no cap)
- it automatically registers the newly obtained dataset as a subdataset (submodule) β if you specified a parent dataset
- it supports extra resource identifiers: DataLad resource identifiers like the ones used on
datasets.datalad.org, and RIA store URLs like the ones used forstore.datalad.orgβ optionally in specific versions identified by a branch or a tag (peep the examples π) - it automatically (and configurably!) generates alternative access URLs for common cases β like appending
'.git'to the URL when hitting the base URL didn't work. so clutch.
In case the clone gets registered as a subdataset, the original URL you passed to CLONE is recorded in .gitmodules of the parent dataset in addition to the resolved URL used internally for git-clone. Why do we care? Because that lets DataLad-specific URLs like ria+ssh://... be preserved for later GET calls β you know, for when the subdataset got locally removed at some point later on. forward-thinking queen behavior π
π URL mapping configuration π
This is about substitution specifications. A substitution specification is defined as a configuration setting datalad.clone.url-substition.<seriesID> whose value is a string containing a match expression and a substitution expression, each following Python's regular expression syntax. The two expressions get concatenated into a single string with an arbitrary delimiter character β and the delimiter itself is defined by prefixing the string with it. Prefix and delimiter get stripped from the expressions.
Example, so it's giving clarity: ",^http://(.*)$,https://1" π
You can define this setting multiple times using the same '<seriesID>'. Substitutions in a series get applied incrementally, in the order they were defined. The first substitution in such a series must match β otherwise no further substitutions in that series will be considered. However! Following the first match, all further substitutions in a series are processed, regardless of whether intermediate expressions match or not. π€
Substitution series themselves have no particular order β each matching series will result in a candidate clone URL. Consequently, that initial match specification in a series should be as precise as possible, to prevent inflation of candidate URLs. be specific, bestie π
π SEEALSO π
handbook:3-001(http://handbook.datalad.org/symbols) β more info on Remote Indexed Archive (RIA) stores π§
π Examples π
Install a dataset from GitHub into the current directory:
% datalad clone https://github.com/datalad-datasets/longnow-podcasts.git
Install a dataset into a specific directory:
% datalad clone https://github.com/datalad-datasets/longnow-podcasts.git myfavpodcasts
Install a dataset as a subdataset into the current dataset:
% datalad clone -d . https://github.com/datalad-datasets/longnow-podcasts.git
Install the main superdataset from datasets.datalad.org:
% datalad clone ///
Install a dataset identified by a literal alias from store.datalad.org:
% datalad clone ria+http://store.datalad.org#~hcp-openaccess
Install a dataset in a specific version as identified by a branch or tag name from store.datalad.org:
% datalad clone ria+http://store.datalad.org#76b6ca66-36b1-11ea-a2e6-f0d5bf7b5561@myidentifier
Install a dataset with group-write access permissions:
% datalad clone http://example.com/dataset --reckless shared-group
π OPTIONS π
SOURCEβ URL, DataLad resource identifier, local path, or an instance of a dataset to be cloned. Constraints: value must be a string.PATHβ path to clone into. If you don't give aPATH, a destination path will be derived from the source URL β similar to howgit clonedoes it. π
π§° GIT CLONE OPTIONS π§°
Options to pass along to git clone. Literally any argument you specify after SOURCE and the optional PATH gets passed to git-clone. π«
β οΈ heads up bestie: not all of these will lead to viable results. For example,'--single-branch'will not result in a functional annex repository, because both a regular branch and thegit-annexbranch are required. Also note that a version in a RIA URL takes precedence over'--branch'.
the actual flags β¨
-h,--help,--help-npβ show this help message.--help-npforcefully disables the use of a pager for displaying the help message (for when the pager is doing too much π).-d DATASET,--dataset DATASETβ (parent) dataset to clone into. If you give this, the newly cloned dataset gets registered as a subdataset of the parent. Also, if given, relative paths are interpreted as being relative to the parent dataset, not relative to the working directory. Constraints: value must be aDatasetor a valid identifier of aDataset(e.g. a path), or value must beNONE.-D DESCRIPTION,--description DESCRIPTIONβ short description to use for a dataset location. Its primary purpose is helping humans identify a dataset copy (like,"mike's dataset on lab server"). Note that when a dataset is published, this information becomes available on the remote side. Constraints: value must be a string or value must beNONE.--reckless [auto|ephemeral|shared-...]β obtain a dataset or subdataset and set it up in a potentially unsafe way, for performance or access reasons. Use with care β any dataset set up this way is marked as'untrusted'. π¬ The reckless mode is stored in a dataset's local configuration under'datalad.clone.reckless', and it will be inherited by any of its subdatasets. Supported modes:['auto']: hard-link files between local clones. In-place modification in any clone will alter original annex content.['ephemeral']: symlink annex to origin's annex and discard local availability info viagit-annex-dead'here', and declares this annex private. Shares an annex between origin and clone w/ogit-annexbeing aware of it. In case of a change in origin you need to update the clone before you're able to save new content on your end. Alternative to'auto'when hardlinks are not an option, or the number of consumed inodes needs to be minimized. Note that this mode can only be used with clones from non-bare repositories or a RIA store! Otherwise two different annex object tree structures (dirhashmixedvsdirhashlower) will be used simultaneously, and annex keys using the respective other structure will be inaccessible. π['shared-<mode>']: set up repository and annex permission to enable multi-user access. This disables the standard write protection of annex'ed files.<mode>can be any value supported by'git init --shared=', such as'group', or'all'.- Constraints: value must be one of (
True,False,'auto','ephemeral') or value must start with'shared-'.
--versionβ show the module and its version which provides the command. π
π AUTHORS π
datalad is developed by The DataLad Team and Contributors <team@datalad.org>. π«Ά
and that's the whole page, bestie!! π¦ this was datalad clone version 1.1.5, dated 2025-06-15 β go forth and clone responsibly, mwah ππβ
π¦ where this page comes from
- debian trixie: datalad 1.1.5-2.1 Β· MIT
- ubuntu resolute: datalad 1.1.5-2.1 Β· MIT
- ubuntu stonking: datalad 1.1.5-2.1 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms