The primary goal for the repository is to provide extensive automated testing of fresh builds of git-annex using its built-in test battery across various base operating systems and environments, and against our downstream DataLad project.
As a side-artifact of the build during the testing process, we provide non-official
automated builds of git-annex. They are attached as artifacts to the CI
runs, and, for the git-annex releases, also to the
Releases page. All build logs
and builds are archived "privately" on an internal server using
con/tinuous, and release builds are then
re-shared from the
///datalad/packages
DataLad package.
These builds are non-official builds of git-annex and their functioning might differ from the official builds.
Agentic AI tools might be used for various aspects of the troubleshooting, development, and maintenance in this repository. We strive to provide our best effort for adequate provenance and attribution on AI-assisted work in commit messages, patch headers, and issues.
This repository contains two primary branches:
upstream/master- an unmodified mirror of themasterbranch from the original git-annex repository, andmaster- CI configuration, associated scripts, and potential patches on top ofupstream/master, which are then applied at build time.
As a result, the builds provided here may function differently than the official original builds of git-annex. This repository also contains issues which might be specific to these builds and not necessarily relevant to the original git-annex.
Patches to the git-annex source code can be added by opening a pull request
against master that adds a Git patch file with a .patch file extension to
the patches/ directory; the CI will then build git-annex with this patch (and
any others currently in patches/) applied. If the patch fails to apply or
appears to have already been applied upstream, the builds will fail.
It is recommended that patches be given names of the form
YYYYMMDD-{commit}-{brief_description}.patch, where {commit} is the short
hash of the git-annex source code commit against which the patch was made.
New patches should carry a
DEP-3 header at the top of
the file (git apply ignores the preamble), including SPDX tags so the
patch remains REUSE compliant on its own:
Description: <one-line summary>
<if needed - longer explanation: why this patch exists in con/git-annex,
what it works around, and who benefits>
Origin: vendor, https://github.com/con/git-annex/commit/<sha>
Author: Your Name <you@example.org>
Forwarded: not-needed # or: <URL of upstream submission>
Last-Update: YYYY-MM-DD
SPDX-FileCopyrightText: YEAR Your Name <you@example.org>
SPDX-License-Identifier: AGPL-3.0-or-later
---
diff --git a/...
Once a patch PR is merged into master, the patch will be applied to all
git-annex builds on all platforms, including release builds. Patches in
patches/ are applied in lexicographic filename order. If a patch in
patches/ gets applied upstream, a PR will automatically be created to delete
the file from patches/, and the patch will be skipped. If a patch fails to
apply, an issue will be automatically created in this repository, and the build
will fail.
Files in the master branch (this branch) are
REUSE compliant — see REUSE.toml
and LICENSES/ for the authoritative, machine-readable
copyright and license information. In short:
- Repository scaffolding (CI workflows, test drivers, docs, README) is licensed MIT © DataLad Team.
- Files under
patches/modify upstream git-annex source and are therefore licensed AGPL-3.0-or-later. Each patch carries a DEP-3 header documenting its description, origin, author, and upstream-forwarding status.
The
upstream/master
branch is an unmodified mirror of git-annex upstream and follows the
licensing of that source tree (AGPL-3.0-or-later as a whole, with
component-level licenses recorded in upstream's own COPYRIGHT file).
| Client | Test Status |
|---|---|
| openmind7 |    |
| ndoli |    |
| smaug |   |
