Two pinned versions, four status badges, and a quick tour that leaves the details to yadm.io

The quick tour is six commands, and each feature bullet links away

The whole working example fits in one indented block: `yadm init` initializes a new repository, `yadm clone <url>` takes an existing one, then `yadm add <important file>` and `yadm commit` record a change. Nothing in that sequence uses a Git flag directly, and the feature list explains why: yadm is based on Git with the full range of Git features. What the block does not do is pick a file to manage, choose an encryption backend, or say where anything is stored. Every feature bullet is a link instead, five of them, pointing at separate pages for alternate files, templates, encryption, bootstrap and hooks, with the sentence that complete features, usage, examples and installation instructions are on yadm.io. So the README is an index: the tour proves the tool works, the bullets tell you which five subjects to read about.

The OBS badge pins v3.5.0 while the release badge asks GitHub for a tag

Read the badge row left to right and two different mechanisms sit side by side. The homebrew, Arch and latest-version badges all fetch their number at render time: `img.shields.io/homebrew/v/yadm.svg` and the Arch one both name a package path, and the release badge queries the repository tag. The OBS badge is a static image with the version typed into the URL itself, `img.shields.io/badge/OBS-v3.5.0-blue`, so it renders the same string until somebody edits the README. Its link goes to an openSUSE download page for a user project, and that project name is the third naming scheme in the row alongside Homebrew and Arch. Meanwhile the release badge points at the GitHub releases page, which is worth knowing when reading version claims elsewhere: this repository has no GitHub releases, so whatever that badge resolves to is coming from tags.

The default branch is develop, and the license badge still points at master

The default branch is develop, and the four status badge images for master, develop, gh-pages and dev-pages all query the same `test.yml` workflow with the branch as a parameter. The master and develop badges link to the Tests workflow, while the gh-pages and dev-pages badges link to a workflow named test site. The date badges follow the same split, with last-commit images for master, develop and gh-pages. Into that arrangement the license badge links to a file on master, `blob/master/LICENSE`, and the project's development and website work happens elsewhere. Anyone scripting against raw file URLs should notice that the branch in the README's own links and the branch the repository develops on are not the same one.

make with no target prints usage through a pager

The default target is not the test suite. `all` depends on nothing and its recipe re-invokes make on the usage target, piping the output through less:

.PHONY: all
all:
	@$(MAKE) usage | less

So a bare `make` in a fresh checkout shows help text and nothing else, and the help text is a long run of echo lines assembled by hand rather than parsed from anything. The same recipe declares `usage` phony alongside it, which keeps the pager output from being mistaken for an up-to-date file named usage. Read together with the target list that follows, this is a project whose contributor entry point is documentation first: `make test` for the suite, `make testhost` for a container to poke at, `make scripthost` for a reproducible bug report, `make testenv` for a linting environment. The variable at the top of the file, `PYTESTS = $(wildcard test/test_*.py)`, suggests the suite is collected by filename pattern from the test directory.

The container image is a dated tag, and version= wires any ref in as a volume

Two variables decide what the container targets run against: `OCI = docker` names the tool, and `IMAGE = docker.io/yadm/testbed:2024-11-11` pins the image to a tag carrying a date rather than a floating latest. The usage text explains what the two host targets do with it. `make testhost` creates an ephemeral container for ad hoc testing and uses the working copy unless a version is given; a version can be any commit, branch or tag, and whichever ref you name is linked into the container as a local volume. `make scripthost` works the same way but for demonstrating a bug, and after you exit its shell it writes the commands you used into a file named script.txt, intended as the starting point for a repeatable test. Both targets are therefore reproducible by ref, at the cost of an image tag that has to be bumped deliberately when the testbed changes.

The usage text for the linting environment stops after three words

Every target's help text is a sequence of echo lines inside the Makefile. The entry for `make testenv` says it creates a python virtual environment with the same dependencies used by yadm's testbed environment, and that creating and activating it might be useful if your editor does real time linting of python files.

Lint limits sit high, one message class is off, and pytest caches in /tmp

pyproject.toml holds the whole quality configuration, and the numbers are set well above the defaults a Python project inherits. Pylint's design limits allow 14 arguments, 10 positional arguments, 28 locals, 8 attributes and 65 statements in a function; the format limit is 120 characters per line. The only message class disabled is redefined-outer-name, which is the standard concession for test modules, and the similarity checker is told to ignore imports and to report at 8 similar lines. Black and isort both use a line length of 120, with isort on the black profile, so the three tools agree on width. The pytest section sets its cache directory to /tmp, adds `-ra` to the default arguments, and registers a marker named deprecated, annotated with a comment explaining that it marks tests for deprecated features and can be deselected with `-m "not deprecated"`. A deprecated-feature marker implies there is a deprecation path being tracked in the test suite, though the config does not say what is deprecated.

One executable ships beside a man page, an RPM spec and a completion directory

The top level is mostly packaging rather than code: a single executable named yadm, its documentation as yadm.1 and yadm.md, an RPM spec file in yadm.spec, directories for completion, contrib and test, and a top-level file named bootstrap. The man page exists in two forms, a compiled-looking page and a markdown original, which fits a project that also maintains a site, since the site content lives on its own gh-pages branch and the badge row tracks that branch separately. yadm.spec covers the RPM side of distribution while Homebrew, Arch and OBS have their own package pages in the badge row, so the repository itself only carries one packaging recipe. Alongside those sit CHANGES and CONTRIBUTORS at the top level, and lint configuration split between pyproject.toml and a .flake8 file, with the pytest, pylint, black and isort settings all living in the former.

Editorial conclusion

yadm suits people who already want Git as the substrate for their dotfiles, and the README is honest about that division of labour: the tour shows six commands, everything else lives on yadm.io. Before you rely on it, check the version question yourself, because the badge row pins OBS at v3.5.0 while the tag badge reads live and the repository publishes no GitHub releases, and the license link points at master although the default branch is develop. For contributors, the practical notes are the dated container image, the four status badges spread over two workflows, and the lint ceiling in pyproject.toml, which is high enough that most style problems will not be caught for you. Anyone planning to add encrypted files should read the encryption page first, since the tour shows the encrypt file but not which backend fills it.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. yadm-dev/yadm on GitHub