DARCS(1)

📦

version 2.18.5 · 5 versions

2.18.5 · alpine 3.24, arch rolling, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu resolute, ubuntu stonking (latest)
2.18.2 · epel 10
2.14.5 · ubuntu jammy
2.16.5 · debian bookworm, epel 9
2.18.4 · debian trixie, ubuntu questing

, in alpine 3.24, arch rolling, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu resolute, ubuntu stonking

DARCS(1) — General Commands Manual

💖 NAME 💖

darcs — an advanced revision control system

🌈 SYNOPSIS 🌈

darcs command <arguments|[options]>...

where the commands and their respective arguments are:

darcs help [<darcs_command> [darcs_subcommand]]
darcs initialize [<directory>]
darcs add <file|directory> ...
darcs whatsnew [file|directory]...
darcs record [file|directory]...
darcs clone <repository> [<directory>]
darcs pull [repository]...
darcs push [repository]
darcs move <source> ... <destination>
darcs remove <file|directory> ...
darcs replace <old> <new> <file> ...
darcs log [file|directory]...
darcs annotate [file|directory]
darcs diff [file|directory]...
darcs show contents [file]...
darcs show dependencies
darcs show files [file|directory]...
darcs show index
darcs show pristine
darcs show repo
darcs show authors
darcs show tags
darcs show patch-index
darcs test [[initialization] command]
darcs revert [file|directory]...
darcs unrevert
darcs amend [file|directory]...
darcs rebase pull [repository]...
darcs rebase apply <patchfile>
darcs rebase suspend
darcs rebase unsuspend
darcs rebase edit
darcs rebase obliterate
darcs rebase log
darcs rebase upgrade
darcs rollback [file|directory]...
darcs unrecord
darcs obliterate
darcs clean [file|directory]...
darcs tag [tagname]
darcs setpref <pref> <value>
darcs send [repository]
darcs apply <patchfile>
darcs optimize clean
darcs optimize http
darcs optimize reorder
darcs optimize enable-patch-index
darcs optimize disable-patch-index
darcs optimize compress
darcs optimize uncompress
darcs optimize relink
darcs optimize upgrade
darcs optimize cache
darcs dist
darcs mark-conflicts [file|directory]...
darcs repair
darcs convert darcs-2 <source> [<destination>]
darcs convert export
darcs convert import [<directory>]
darcs fetch [repository]...

💫 DESCRIPTION 💫

okay bestie, here's the tea: unlike conventional revision control systems, Darcs is based on tracking changes, not versions. It can and does automatically re-order independent changes when needed. That means in Darcs the state of a repository should be regarded as a set of patches rather than a sequence of versions. periodt.

Another distinguishing feature of darcs is that most commands are interactive by default. For instance, darcs record (the equivalent of what is usually called commit) presents you with each unrecorded change and asks you whether it should be included in the patch to be recorded. Similarly, darcs push and darcs pull present you with each patch, allowing you to select which patches to push or pull. it's giving choose-your-own-adventure but for patches 💅.

✨ OPTIONS ✨

Different options are accepted by different Darcs commands. Each command's most important options are listed in the COMMANDS section. For a full list of all options accepted by a particular command, run darcs command --help. iykyk.

💅 Selecting Patches 💅

The --patches option yields patches with names matching an extended regular expression. See regex(7) for details. The --matches option yields patches that match a logical (Boolean) expression: one or more primitive expressions combined by grouping (parentheses) and the complement (not), conjunction (and) and disjunction (or) operators. The C notation for logic operators (!, && and ||) can also be used. no cap.

--patches=regex is a synonym for --matches='name regex'
--hash=HASH is a synonym for --matches='hash HASH'
--from-patch and --to-patch are synonyms for
  --from-match='name... and --to-match='name...
--from-hash and --to-hash are synonyms for
  --from-match='hash...' and --to-match='hash...'
sensible combinations of --from-* and --to-* options are possible:
  darcs log --from-patch='html.*docu' --to-match='date 20040212'
  darcs log --from-hash=368089c6969 --to-patch='^fix.*renamed or moved.$'

The following primitive Boolean expressions are supported:

exact STRING — check literal STRING is equal to patch name.
name REGEX — match REGEX against patch name.
author REGEX — match REGEX against patch author.
hunk REGEX — match REGEX against contents of a hunk patch.
comment REGEX — match REGEX against the full log message.
hash HASH — match HASH against (a prefix of) the hash of a patch.
date DATE — match DATE against the patch date.
touch REGEX — match file paths for a patch.

Here are some examples:

darcs log --match 'exact "Resolve issue17: use dynamic memory allocation."'
darcs log --match 'name issue17'
darcs log --match 'name "^[Rr]esolve issue17>"'
darcs log --match 'author "David Roundy"'
darcs log --match 'author droundy'
darcs log --match 'author droundy@darcs.net'
darcs log --match 'hunk "foo = 2"'
darcs log --match 'hunk "^instance .* Foo where$"'
darcs log --match 'comment "prevent deadlocks"'
darcs log --match 'hash c719567e92c3b0ab9eddd5290b705712b8b918ef'
darcs log --match 'hash c7195'
darcs log --match 'date "2006-04-02 22:41"'
darcs log --match 'date "tea time yesterday"'
darcs log --match 'touch src/foo.c'
darcs log --match 'touch src/'
darcs log --match 'touch "src/*.(c|h)"'

👑 COMMANDS 👑

🫶 `darcs help [<darcs_command> [darcs_subcommand]]`

Without arguments, darcs help prints a categorized list of darcs commands and a short description of each one. With an extra argument, darcs help foo prints detailed help about the darcs command foo. it's giving personal tutor energy.

🌸 Most used/starting out: 🌸

🎀 `darcs initialize [<directory>]`

The darcs initialize command creates an empty repository in the current directory. This repository lives in a new _darcs directory, which stores version control metadata and settings. lowkey iconic.

Existing files and subdirectories are not touched. You can record them with darcs record --look-for-adds.

Initialize is commonly abbreviated to init.

Darcs currently supports three kinds of patch semantics. These are called darcs-1, darcs-2, and darcs-3. They are mutually incompatible, that is, you cannot exchange patches between repos with different semantics. fr fr, pick one.

By default, patches of the new repository are in the darcs-2 semantics. However it is possible to create a repository in darcs-1 semantics with the flag --darcs-1, although this is not recommended except for sharing patches with a project that uses patches in the darcs-1 semantics.

The darcs-3 semantics is EXPERIMENTAL and new in version 2.16. It is included only as a technology preview and we do NOT recommend to use it for any serious work. The on-disk format is not yet finalized and we cannot and will not promise that later releases will work with darcs-3 repos created with any darcs version before 3.0.

Initialize and clone commands create the preferences files in _darcs/prefs/ directory of the newly created repository. With option --with-prefs-templates boring and binaries preferences files will be filled with default templates. If you want to leave these files empty use --no-prefs-templates option. If you prefer to keep the relevant settings globally, it will be convenient to add 'ALL no-prefs-templates' to your ~/darcs/defaults file. so many options but we love that for you.

🦋 `darcs add <file|directory> ...`

Generally the working tree contains both files that should be version controlled (such as source code) and files that Darcs should ignore (such as executables compiled from the source code). The darcs add command is used to tell Darcs which files to version control. it's giving VIP list for files.

When an existing project is first imported into a Darcs repository, it is common to run darcs add -r * or darcs record -l to add all initial source files into darcs.

Adding symbolic links (symlinks) is not supported. sorry bestie.

Darcs will ignore all files and folders that look "boring". The --boring option overrides this behaviour.

Darcs will not add a file if another file in the same folder has the same name, except for case. The --case-ok option overrides this behaviour. Windows and OS X usually use filesystems that do not allow files a folder to have the same name except for case (for example, ReadMe and README).

Warning bestie: if --case-ok is used, the repository might be unusable on those systems!

🍓 `darcs whatsnew [file|directory]...`

The darcs whatsnew command lists unrecorded changes to the working tree. If you specify a set of files and directories, only unrecorded changes to those files and directories are listed. it's giving detective mode.

With the --summary option, the changes are condensed to one line per file, with mnemonics to indicate the nature and extent of the change. The --look-for-adds option causes candidates for darcs add to be included in the summary output. WithSummary mnemonics are as follows:

A f and A d/ respectively mean an added file or directory.
R f and R d/ respectively mean a removed file or directory.
M f -N +M rP means a modified file, with N lines deleted, M lines added, and P lexical replacements.
f -> g means a moved file or directory.
a f and a d/ respectively mean a new, but unadded, file or directory, when using --look-for-adds.
An exclamation mark (!) as in R! foo.c, means the change conflicts with a change in an earlier patch. The phrase duplicated means the change is identical to a change in an earlier patch.

The --machine-readable option implies --summary while making it more parsable. Modified files are only shown as M f, and moves are shown in two lines: F f and T g (as in 'From f To g').

By default, darcs whatsnew uses Darcs' internal format for changes. To see some context (unchanged lines) around each change, use the --unified option. (This option has no effect in interactive mode.) To view changes in conventional diff format, use the darcs diff command; but note that darcs diff cannot properly display changes when file renames are involved.

This command exits unsuccessfully (returns a non-zero exit status) if there are no unrecorded changes. no cap, it will be sad.

🧚 `darcs record [file|directory]...`

The darcs record command is used to create a patch from changes in the working tree. If you specify a set of files and directories, changes to other files will be skipped.

Every patch has a name, an optional description, an author and a date. main character patch energy 💅.

Darcs will pop open a text editor for you (peep darcs help environment for the deets on which one) after the interactive selection, so you can type in the patch name (that's the first line) and then the patch description (everything after that, bestie).

You can also just hand over the patch name in advance with the -m option — in that case no editor gets launched at all, unless you specifically ask for --edit-long-comment. 💅

The patch description is an optional block of free-form text. It's your little space for extra info that doesn't fit in the patch name — like, say, the reason WHY the change was even necessary. Big brain energy.

Okay so here's a technical difference between patch name and patch description that you need to know: matching with the -p flag only ever happens on patch names. Names only, no cap. 🎯

And then there's --logfile, which lets you feed in a file that already has the patch name and description sitting in it. Super handy if a previous record failed and left a _darcs/patch_description.txt file lying around.

Every patch gets attributed to its author, usually by email address (think Fred Bloggs <fred@example.net>). Darcs goes hunting for that author string in a whole bunch of places: the --author option, the files _darcs/prefs/author (in the repository) and ~/.darcs/author (in your home directory), and the environment variables $DARCS_EMAIL and $EMAIL. If literally none of those exist, Darcs will prompt you for an author string and write it to ~/.darcs/author. And heads up — if you've got more than one email address, you can put them all in ~/.darcs/author, one author per line. Darcs will still prompt you for an author, but it lets you pick from that list, or type in something else entirely. 🫶

If you want to manually define any explicit dependencies for your patch, hit up the --ask-deps flag. Some dependencies may get automatically inferred from the patch's content, and those ones cannot be removed. Fun fact: a patch with specific dependencies can be totally empty. 💀

The patch date is generated automatically. It can only be spoofed by using the --pipe option. Only. Periodt.

If you run record with the --pipe option, you'll be prompted for the patch date, the author, and the long comment. That long comment just keeps going until the end of file or stdin is reached. This interface is intended for scripting darcs, in particular for writing repository conversion scripts. The prompts are mostly there as a useful guide (since scripts won't need them anyway), to help you understand the input format. Here's what the --pipe prompts look like:

What is the date? Mon Nov 15 13:38:01 EST 2004
Who is the author? David Roundy
What is the log? One or more comment lines

If a test command has been defined with darcs setpref, attempting to record a patch will cause that test command to run in a clean copy of the working tree (that means including only recorded changes). If the test fails, you'll be offered to abort the record operation. 😭

The --set-scripts-executable option causes scripts to be made executable in the clean copy of the working tree, prior to running the test. See darcs clone for an explanation of the script heuristic.

If your test command is tediously slow (we're talking make all levels of slow) and you're recording several patches in a row, you may wish to use --no-test to skip all but the final test. Your patience is the main character here. ✨

And to see some context (those unchanged lines) around each change, use the --unified option.

🌈 `darcs clone <repository> [<directory>]` 🌈

Clone creates a copy of a repository. That optional second argument specifies a destination directory for the new copy — and if you leave it out, it gets inferred from the source location. Iconic, honestly.

By default Darcs will copy every patch from the original repository. If you expect the original repository to stay accessible, you can use --lazy to avoid copying patches until they're actually needed (that's 'copy on demand', iykyk). This is particularly useful when you're copying a remote repository with a long history that you genuinely do not care about.

When cloning locally, Darcs automatically uses hard linking where possible. As well as saving time and space, this enables you to move or delete the original repository without affecting the copy. Hard linking requires that the copy be on the same filesystem as the original repository, and that the filesystem support hard linking. That includes NTFS, HFS+ and all general-purpose Unix filesystems (such as ext, UFS and ZFS). FAT does not support hard links. 🚫

When cloning from a remote location, Darcs will look for and attempt to use packs created by darcs optimize http in the remote repository. Packs are single big files that can be downloaded faster than many little files. Fewer files, faster vibes. ⭐

Darcs clone will not copy unrecorded changes to the source repository's working tree.

You can copy a repository to a ssh url, in which case the new repository will always be complete.

It is often desirable to make a copy of a repository that excludes some patches. For example, if releases are tagged then darcs clone --tag . would make a copy of the repository as at the latest release. An untagged repository state can still be identified unambiguously by a context file, as generated by darcs log --context. Given the name of such a file, the --context option will create a repository that includes only the patches from that context. When a user reports a bug in an unreleased version of your project, the recommended way to find out exactly what version they were running is to have them include a context file in the bug report. You can also make a copy of an untagged state using the --to-patch or --to-match options, which exclude patches after the first matching patch. And because these options treat the set of patches as an ordered sequence, you may get different results after reordering with darcs optimize reorder. Order matters, bestie. 🔥

The --set-scripts-executable option causes scripts to be made executable in the working tree. A script is any file that starts with a shebang ("#!").

The --inherit-default option is meant to support a work flow where you have different branches of the same upstream repository and want all your branches to have the same upstream repo as the defaultrepo. It is most useful when enabled globally by adding 'ALL --inherit-default' to your ~/darcs/defaults file.

For the clone command it means the following: If the source repository already has a defaultrepo set (either because you cloned it or because you explicitly used the --set-default option), and both source and target are locally valid paths on the same host, then the target repo will get the same defaultrepo as the source repo. Otherwise the target repo gets the source repo itself as defaultrepo, i.e. we fall back to the defalt behavior (--no-inherit-default).

Initialize and clone commands create the preferences files in _darcs/prefs/ directory of the newly created repository. With option --with-prefs-templates boring and binaries preferences files will be filled with default templates. If you want to leave these files empty use --no-prefs-templates option. If you prefer to keep the relevant settings globally, it will be convenient to add 'ALL no-prefs-templates' to your ~/darcs/defaults file.

💜 `darcs pull [repository]...` 💜

Pull is used to bring patches made in another repository into the current repository (that is, either the one in the current directory, or the one specified with the --repodir option). Pull accepts arguments, which are URLs from which to pull, and when called without an argument, pull will use the repository specified at _darcs/prefs/defaultrepo.

The default (--union) behavior is to pull any patches that are in any of the specified repositories. If you specify the --intersection flag, darcs will only pull those patches which are present in all source repositories. And if you specify the --complement flag, darcs will only pull elements in the first repository that do not exist in any of the remaining repositories. Pick your fighter. 🥊

If --reorder is supplied, the set of patches that exist only in the current repository is brought at the top of the current history. This will work even if there are no new patches to pull. No new patches? Still works. Slay.

For the commands push, pull, and send it means the following: Changes the meaning of the --set-default option so that it sets the (local) defaultrepo to the defaultrepo of the remote repo, instead of the remote repo itself. This happens only if the remote repo does have a defaultrepo set and both local and remote repositories are locally valid paths on the same host, otherwise fall back to the default behavior (--no-inherit-default).

See darcs help apply for detailed description of many options. 📚

🎀 `darcs push [repository]` 🎀

Push is the opposite of pull. Push allows you to copy patches from the current repository into another repository. Two sides of the same coin, fr fr.

The --reorder-patches option works in the same way as it does for pull and apply: instead of placing the new patches (coming from your local repository) on top of (i.e. after) the existing (remote) ones, it puts the remote-only patches on top of the ones that you are pushing. This can be useful, for instance, if you have recorded a tag locally and want this tag to be clean in the remote repository after pushing. Clean tag, clean conscience. ✨

If you give the --apply-as flag, darcs will use sudo to apply the patches as a different user. This can be useful if you want to set up a system where several users can modify the same repository, but you don't want to allow them full write access.

🚨 Okay important caveat time: this isn't secure against skilled malicious attackers, but at least can protect your repository from clumsy, inept or lazy users. Know what you're signing up for!

darcs push will compress the patch data before sending it to a remote location via ssh. This works as long as the remote darcs is not older than version 2.5. If you get errors that indicate a corrupt patch bundle, you should try again with the --no-compress option. 🦋

--inherit-default is here to support a whole work flow vibe ✨ — the one where you've got different branches of the same upstream repository and you want all your branches to have the same upstream repo as the defaultrepo. It's most useful when you enable it globally by adding ALL --inherit-default to your ~/darcs/defaults file.

For the commands push, pull, and send it means the following:

It changes the meaning of the --set-default option so that it sets the (local) defaultrepo to the defaultrepo of the remote repo, instead of the remote repo itself. This happens only if the remote repo does have a defaultrepo set and both local and remote repositories are locally valid paths on the same host — otherwise we fall back to the default behavior (--no-inherit-default).

🌸 Preparing patches before recording 🌸

darcs move <source> ... <destination> 🦋

Darcs literally cannot reliably tell the difference between a file getting deleted plus a new one getting added, versus a file being moved. So Darcs always assumes the former, and hands you the darcs mv command so you can tell it when you actually mean the latter. This command will also move the file in the working tree (unlike darcs remove), unless it has already been moved. 💅

Darcs will not rename a file if another file in the same folder has the same name, except for case. The --case-ok option overrides this behaviour. Windows and OS X usually use filesystems that do not allow files a folder to have the same name except for case (for example, ReadMe and README).

🚨 If --case-ok is used, the repository might be unusable on those systems! Like, fr fr, be careful. 😭

darcs remove <file|directory> ... 🎀

The darcs remove command exists primarily for symmetry with darcs add, because the normal way to remove a file from version control is simply to delete it from the working tree. This command is only useful in the unusual case where one wants to record a removal patch WITHOUT deleting the copy in the working tree (which can be re-added). 🙈

Note that applying a removal patch to a repository (e.g. by pulling the patch) will ALWAYS affect the working tree of that repository.

darcs replace <old> <new> <file> ... 💜

On top of line-based patches, Darcs supports a limited form of lexical substitution. Files are treated as sequences of words, and each occurrence of the old word is replaced by the new word. This is intended to provide a clean way to rename a function or variable. Such renamings typically affect lines all through the source code, so a traditional line-based patch would be very likely to conflict with other branches, requiring manual merging. (Not the vibe. 🫠)

Files are tokenized according to one simple rule: words are strings of valid token characters, and everything between them (punctuation and whitespace) is discarded. By default, valid token characters are letters, numbers and the underscore (i.e. [A-Za-z0-9_]). However if the old and/or new token contains either a hyphen or period, BOTH hyphen and period are treated as valid (i.e. [A-Za-z0-9_.-]).

The set of valid characters can be customized using the --token-chars option. The argument must be surrounded by square brackets. If a hyphen occurs between two characters in the set, it is treated as a set range. For example, in most locales [A-Z] denotes all uppercase letters. If the first character is a caret, valid tokens are taken to be the complement of the remaining characters. For example, [^:0 could be used to match fields in the passwd(5), where records and fields are separated by newlines and colons respectively.

If you choose to use --token-chars, you are STRONGLY encouraged to do so consistently. The consequences of using multiple replace patches with different --token-chars arguments on the same file are not well tested nor well understood. 💀

By default Darcs will refuse to perform a replacement if the new token is already in use, because the replacements would be not be distinguishable from the existing tokens. This behaviour can be overridden by supplying the --force option, but an attempt to darcs rollback the resulting patch will affect these existing tokens.

Limitations: ⚠️

The tokenizer treats files as byte strings, so it is not possible for --token-chars to include multi-byte characters, such as the non-ASCII parts of UTF-8. Similarly, trying to replace a "high-bit" character from a unibyte encoding will also result in replacement of the same byte in files with different encodings. For example, an acute a from ISO 8859-1 will also match an alpha from ISO 8859-7.

Due to limitations in the patch file format, --token-chars arguments cannot contain literal whitespace. For example, [^ ] cannot be used to declare all characters except the space, tab and newline as valid within a word, because it contains a literal space.

Unlike POSIX regex(7) bracket expressions, character classes (such as [[:alnum:]]) are NOT supported by --token-chars, and will be silently treated as a simple set of characters. 🚫

🔍 Querying the repository 🔍

darcs log [file|directory]... ⭐

The darcs log command lists patches of the current repository or, with --repo, a remote repository. Without options or arguments, ALL patches will be listed. 👑

When given files or directories paths as arguments, only patches which affect those paths are listed. This includes patches that happened to files before they were moved or renamed.

When given --from-tag or --from-patch, only patches since that tag or patch are listed. Similarly, the --to-tag and --to-patch options restrict the list to older patches.

The --last and --max-count options both limit the number of patches listed. The former applies BEFORE other filters, whereas the latter applies AFTER other filters. For example darcs log foo.c --max-count 3 will print the last three patches that affect foo.c, whereas darcs log --last 3 foo.c will, of the last three patches, print only those that affect foo.c. See how different those are?? 🤯

Four output formats exist. The default is --human-readable. The slightly different --machine-readable format enables to see patch dependencies in non-interactive mode. You can also select --context, which is an internal format that can be re-read by Darcs (e.g. darcs clone --context).

Finally, there is --xml-output, which emits valid XML... unless a the patch metadata (author, name or description) contains a non-ASCII character and was recorded in a non-UTF8 locale. 🫠

darcs annotate [file|directory] 🦋

When darcs annotate is called on a file, it will find the patch that last modified each line in that file. This also works on directories.

The --machine-readable option can be used to generate output for machine postprocessing.

darcs diff [file|directory]... 🌈

The darcs diff command compares two versions of the working tree of the current repository. Without options, the pristine (recorded) and unrecorded working trees are compared. This is lower-level than the darcs whatsnew command, since it outputs a line-by-line diff, and it is also slower. As with darcs whatsnew, if you specify files or directories, changes to other files are not listed. The command always uses an external diff utility.

With the --patch option, the comparison will be made between working trees with and without that patch. Patches after the selected patch are not present in either of the compared working trees. The --from-patch and --to-patch options allow the set of patches in the old and new working trees to be specified separately.

The associated tag and match options are also understood, e.g. darcs diff --from-tag 1.0 --to-tag 1.1. All these options assume an ordering of the patch set, so results may be affected by operations such as darcs optimize reorder.

diff(1) is always called with the arguments -rN and by default also with -u to show the differences in unified format. This can be turned off by passing --no-unified. An additional argument can be passed using --diff-opts, such as --diff-opts=-ud or --diff-opts=-wU9.

The --diff-command option can be used to specify an alternative utility. Arguments may be included, separated by whitespace. The value is not interpreted by a shell, so shell constructs cannot be used. The arguments %1 and %2 MUST be included, these are substituted for the two working trees being compared. For instance:

darcs diff -p . --diff-command "meld %1 %2"

If this option is used, --diff-opts is ignored.

darcs show subcommand ✨

Display various information about a repository. See description of the subcommands for details.

darcs show contents [file]... 🍓

Show contents can be used to display an earlier version of some file(s). If you give show contents no version arguments, it displays the recorded version of the file(s).

darcs show dependencies 🕸️

This command creates a graph of the dependencies between patches. The output format is the Dot Language, see https://www.graphviz.org/doc/info/lang.html. The resulting graph is transitively reduced, in other words, it contains only the direct dependencies, not the indirect ones.

By default all patches in your repository are considered. You can limit this to a range of patches using patch matching options, see darcs help patterns and the options avaiable for this command. For instance, to visualize the dependencies between all patches since the last tag, do:

darcs show dependencies --from-tag=. | dot -Tpdf -o FILE.pdf

This command can take a very(!) long time to compute its result, depending on the number of patches in the selected range. For N patches it needs to do on the order of N^3 commutations in the worst case. 😮‍💨

darcs show files [file|directory]... 🌸

The darcs show files command lists those files and directories in the working tree that are under version control. This command is primarily for scripting purposes; end users will probably want darcs whatsnew --summary.

A file is "pending" if it has been added but not recorded. By default, pending files (and directories) are listed; the --no-pending option prevents this. 💅

By default, darcs show files gives you both files and directories, no cap — but the --no-files and --no-directories flags change that whole vibe.

Also, by default entries come one-per-line (newline separated). Which is fine until a filename has a newline or some other control character in it and everything goes 💀. To dodge that, the --null option uses the null character instead. The script reading this output has to understand that idiom — and xargs -0 is exactly such a command. iykyk.

So like, to list version-controlled files by size:

darcs show files -0 | xargs -0 ls -ldS

🌸 `darcs show index`

The darcs show index command lists all version-controlled files and directories along with their hashes as stored in _darcs/index. For files, the fields correspond to file size, sha256 of the current file content and the filename. That's it, that's the tea. 🫖

🦋 `darcs show pristine`

The darcs show pristine command lists all version-controlled files and directories along with the hashes of their pristine copies. For files, the fields correspond to file size, sha256 of the pristine file content and the filename. Sibling energy with show index, just pristine-flavoured. ✨

👑 `darcs show repo`

The darcs show repo command displays statistics about the current repository, letting third-party scripts peek at this info without inspecting _darcs directly — and without everything breaking when the _darcs format changes. Honestly? Iconic design choice. 💅

The 'Weak Hash' identifies the set of patches of a repository independently of ordering. It can be used to easily compare two repositories of a same project. It is not cryptographically secure, bestie — do not use it for security things, fr fr.

By default, output includes statistics that require walking through the patches recorded in the repository, namely the 'Weak Hash' and the count of patches. If you don't need that data, use --no-enum-patches to accelerate this command from O(n) to O(1). Glow-up speed. 🔥

By default, output is in a human-readable format. The --xml-output option can be used to generate output for machine postprocessing.

💜 `darcs show authors`

The darcs show authors command lists the authors of the current repository, sorted by the number of patches contributed. With the --verbose option, this command simply lists the author of each patch (without aggregation or sorting). No sorting, no grouping, just raw author strings in a row. 🙈

An author's name or email address may change over time. To tell Darcs when multiple author strings refer to the same individual, create an .authorspellings file in the root of the working tree. Each line in this file begins with an author's canonical name and address, and may be followed by a comma separated list of extended regular expressions. Blank lines and lines beginning with two hyphens are ignored. The format of .authorspelling can be described by this pattern:

name <address> [, regexp ]*

There are some pitfalls concerning special characters: Whitespaces are stripped, if you need space in regexp use [ ]. Because comma serves as a separator you have to escape it if you want it in regexp. Note that .authorspelling use extended regular expressions so +, ? and so on are metacharacters and you need to escape them to be interpreted literally.

Any patch with an author string that matches the canonical address or any of the associated regexps is considered to be the work of that author. All matching is case-insensitive and partial (it can match a substring). Use ^,$ to match the whole string in regexps.

Currently this canonicalization step is done only in darcs show authors. Other commands, such as darcs log use author strings verbatim. So don't expect the magic everywhere, okay? 😭

An example .authorspelling file is:

-- This is a comment.
Fred Nurk <fred@example.com>
John Snagge <snagge@bbc.co.uk>, John, snagge@, js@(si|mit).edu
Chuck Jones Jr. <chuck@pobox.com>, cj+user@example.com

🎀 `darcs show tags`

The tags command writes a list of all tags in the repository to standard output.

Tab characters (ASCII character 9) in tag names are changed to spaces for better interoperability with shell tools. A warning is printed if this happens. So if you see a warning, it's not you, it's the tabs. 🍓

⭐ `darcs show patch-index`

When given the --verbose flag, the command darcs show patch-index dumps the complete content of the patch index and checks its integrity. Very forensic of it. 🔍

💅 Undoing and correcting:

🧚 `darcs revert [file|directory]...`

The darcs revert command discards unrecorded changes in the working tree. As with darcs record, you will be asked which hunks (changes) to revert. The --all switch can be used to avoid such prompting. If files or directories are specified, other parts of the working tree are not reverted.

In you accidentally reverted something you wanted to keep (for example, typing darcs rev -a instead of darcs rec -a), you can immediately run darcs unrevert to restore it. This is only guaranteed to work if the repository has not changed since darcs revert ran.

Lowkey a classic. One letter, whole afternoon gone. rev vs rec, be careful bestie. 😭

🌈 `darcs unrevert`

Unrevert is a rescue command in case you accidentally reverted something you wanted to keep (for example, typing darcs rev -a instead of darcs rec -a). The emergency undo button. 🫶

This command may fail if the repository has changed since the revert took place. Darcs will ask for confirmation before executing an interactive command that will DEFINITELY prevent unreversion.

✨ `darcs amend [file|directory]...`

Amend updates a "draft" patch with additions or improvements, resulting in a single "finished" patch.

By default amend proposes you to record additional changes. If instead you want to remove changes, use the flag --unrecord.

When recording a draft patch, it is a good idea to start the name with DRAFT:. When done, remove it with darcs amend --edit-long-comment. Alternatively, to change the patch name without starting an editor, use the --name/-m flag:

darcs amend --match 'name "DRAFT: foo"' --name 'foo2'

Like darcs record, if you call amend with files as arguments, you will only be asked about changes to those files. So to amend a patch to foo.c with improvements in bar.c, you would run:

darcs amend --match 'touch foo.c' bar.c

Note that this command edits the history of your repo. It is primarily intended to be used on patches that you authored yourself and did not yet publish. Using it for patches that are already published, or even ones you did not author yourself, may cause confusion and can disrupt your own and other people's work-flow. This depends a lot on how your project is organized, though, so there may be valid exceptions to this rule. So like... read the room before you rewrite history, okay? 💀

Using the --not-in-remote option is a good way to guard against accidentally editing published patches. Without arguments, this deselects any patches that are also present in the defaultrepo. If you work in a clone of some publically hosted repository, then your defaultrepo will be that public repo. You can also give the option an argument which is a path or URL of some other repository; you can use the option multiple times with different repositories, which has the effect of treating all of them as "upstream", that is, it prevents you from selecting a patch that is contained in any of these repos.

You can also guard only against editing another developer's patch by using an appropriate --match option with the author keyword. For instance, you could add something like <cmd> match Your Name to your ~/.darcs/defaults.

🦋 `darcs rebase subcommand`

The `darcs rebase' command is used to edit a collection of darcs patches.

The basic idea is that you can suspend patches from the end of a repository. These patches are no longer part of the history and have no effect on the working tree. Suspended patches are invisible to commands that access the repository from the outside, such as push, pull, clone, send, etc.

The sequence of suspended patches can be manipulated in ways that normal patches would never allow, bestie. Like, for instance, darcs rebase obliterate lets you yeet a patch out of that sequence even if other suspended patches depend on it. And those other patches? They become conflicted as a result. 💀 It's giving consequences.

You can also operate on the normal patches in the usual way. And if you add or remove normal patches, the suspended patches get automatically adapted so they still apply to the pristine state — possibly becoming conflicted in the course of that. No cap, it just happens.

⚠️ Note that as soon as a patch gets suspended, it will irrevocably lose its identity. So suspending a patch is subject to the usual warnings about editing the history of your project. Irrevocably. Gone. 🫠

The opposite of suspending a patch is to unsuspend it. That turns it back into a normal patch. If the patch is conflicted as a result of previous operations on either the normal patches or the suspended patches, unsuspending will create appropriate conflict markup. But note — the unsuspended patch itself WILL NOT BE CONFLICTED itself. Which means there is no way to re-generate the conflict markup. Once you removed it, by editing files or using darcs revert, any information about the conflict is lost forever. 😭

As long as you have suspended patches, darcs will display a short message after each command to remind you that your patch editing operation is still in progress. It's like a little sticky note from your repo. 🎀

`darcs rebase pull [repository]...`

Copy and apply patches from another repository, suspending any local patches that conflict. 💅

`darcs rebase apply <patchfile>`

Apply a patch bundle, suspending any local patches that conflict. Same vibe, different source. ✨

`darcs rebase suspend`

Select patches to move into a suspended state at the end of the repo. 🦋

⚠️ Note that this command edits the history of your repo. It is primarily intended to be used on patches that you authored yourself and did not yet publish. Using it for patches that are already published, or even ones you did not author yourself, may cause confusion and can disrupt your own and other people's work-flow. This depends a lot on how your project is organized, though, so there may be valid exceptions to this rule.

Using the --not-in-remote option is a good way to guard against accidentally editing published patches. Without arguments, this deselects any patches that are also present in the defaultrepo. If you work in a clone of some publically hosted repository, then your defaultrepo will be that public repo. You can also give the option an argument which is a path or URL of some other repository; you can use the option multiple times with different repositories, which has the effect of treating all of them as "upstream" — that is, it prevents you from selecting a patch that is contained in any of these repos. 🫶

`darcs rebase unsuspend`

Select suspended patches to restore to the end of the repo. Welcome back, queen 👑

`darcs rebase edit`

Edit suspended patches. That's it. That's the whole thing. ✨

`darcs rebase obliterate`

Obliterate a patch that is currently suspended. Poof. 💀

`darcs rebase log`

List the currently suspended changes. Perfect for when you forgot what you were doing (relatable).

`darcs rebase upgrade`

Upgrade a repo with an old-style rebase in progress. 🧚

⚠️ Doing this means you won't be able to use darcs version < 2.15 with this repository until the rebase is finished. So like, commit to the bit.

`darcs rollback [file|directory]...`

Rollback is used to undo the effects of some changes from patches in the repository. The selected changes are undone in your working tree, but the repository is left unchanged. First you are offered a choice of which patches to undo, then which changes within the patches to undo. Two-step selection, very main character energy. 🎀

Before doing rollback, you may want to temporarily undo the changes of your working tree (if there are) and save them for later use. To do so, you can run revert, then run rollback, record a patch, and run unrevert to restore the saved changes into your working tree. It's a whole little routine — revert → rollback → record → unrevert. Save it in your notes app bestie 📝

`darcs unrecord`

Unrecord does the opposite of record: it deletes patches from the repository without changing the working tree. The changes are now again visible with darcs whatsnew and you can record or revert them as you please. 🦋

⚠️ Note that this command edits the history of your repo. It is primarily intended to be used on patches that you authored yourself and did not yet publish. Using it for patches that are already published, or even ones you did not author yourself, may cause confusion and can disrupt your own and other people's work-flow. This depends a lot on how your project is organized, though, so there may be valid exceptions to this rule.

Using the --not-in-remote option is a good way to guard against accidentally editing published patches. Without arguments, this deselects any patches that are also present in the defaultrepo. If you work in a clone of some publically hosted repository, then your defaultrepo will be that public repo. You can also give the option an argument which is a path or URL of some other repository; you can use the option multiple times with different repositories, which has the effect of treating all of them as "upstream" — that is, it prevents you from selecting a patch that is contained in any of these repos.

`darcs obliterate`

Obliterate completely removes recorded patches from your local repository. The changes will be undone in your working tree and the patches will not be shown in your changes list anymore. Beware that you can lose precious code by obliterating! 😭 Not a drill.

One way to save obliterated patches is to use the -O flag. A patch bundle will be created locally, that you will be able to apply later to your repository with darcs apply. See darcs send for a more detailed description. Safety net secured 🫶

⚠️ Note that this command edits the history of your repo. It is primarily intended to be used on patches that you authored yourself and did not yet publish. Using it for patches that are already published, or even ones you did not author yourself, may cause confusion and can disrupt your own and other people's work-flow. This depends a lot on how your project is organized, though, so there may be valid exceptions to this rule.

Using the --not-in-remote option is a good way to guard against accidentally editing published patches. Without arguments, this deselects any patches that are also present in the defaultrepo. If you work in a clone of some publically hosted repository, then your defaultrepo will be that public repo. You can also give the option an argument which is a path or URL of some other repository; you can use the option multiple times with different repositories, which has the effect of treating all of them as "upstream" — that is, it prevents you from selecting a patch that is contained in any of these repos.

`darcs clean [file|directory]...`

Remove unrecorded changes from the working tree. 🧹

This is an alias for darcs revert -l/--look-for-adds which means it works also on files that have not been added. You can additionally pass --boring to get rid of every unrecorded file or directory. Every. Single. One. 💀

See description of darcs revert for more details.

🌈 Direct modification of the repository:

`darcs tag [tagname]`

The darcs tag command names the current repository state, so that it can easily be referred to later. It does so by recording a special kind of patch that makes no changes and which explicitly depends on all patches currently existing in the repository (except for those which are depended upon by other tags already in the repository). In the common case of a sequential series of tags, this means that the tag depends on all patches since the last tag, plus that tag itself. Iconic behaviour honestly 👑

Every important state should be tagged; in particular it is good practice to tag each stable release with a number or codename. Advice on release numbering can be found at <http://producingoss.com/en/development-cycle.html>. 📖

To reproduce the state of a repository R as at tag t, use the command darcs clone --tag t R. Note however that tags are matched as regular expressions, like with --patch. To make sure you get the right tag it may be better to use darcs clone --tag '^t$'. The command darcs show tags lists all tags in the current repository. 🎀

Tagging also provides significant performance benefits: when Darcs reaches a tag that depends on all preceding patches, it can often stop processing. A tag in such a position is called "clean". For instance, operations like push and pull need to examine only patches that come after the latest shared clean tag. It's giving efficiency, it's giving slay ✨

Like normal patches, a tag has a name, an author, a timestamp and an optional long description, but it does not change the working tree. A tag can have any name, but it is generally best to pick a naming scheme and stick to it. Consistency is the vibe. 💜

By default a tag names the entire repository state at the time the tag is created. If the --ask-deps option is used, the patches to include as part of the tag can be explicitly selected.

The darcs tag command accepts the --pipe option, which behaves as described in darcs record. 🌸

`darcs setpref <pref> <value>`

When working on project with multiple repositories and contributors, it is sometimes desirable for a preference to be set consistently project-wide. This is achieved by treating a preference set with darcs setpref as an unrecorded change, which can then be recorded and then treated like any other patch. So your prefs get to ride along with the repo like a little passenger 🦋

Valid preferences are:

test — a shell command that runs regression tests ✨
predist — a shell command to run before darcs dist 🎀
boringfile — the path to a version-controlled boring file 🙈
binariesfile — the path to a version-controlled binaries file 💾

So like, say your project uses GNU autotools and you've got a make test target doing your regression tests? You can turn on Darcs' built-in regression testing like this:

darcs setpref test 'autoconf && ./configure && make && make test'

Okay bestie, important caveat: merging is not currently implemented for preferences. If two patches try to set the same preference, the last patch applied to the repository always wins. It's considered a low-priority bug, because honestly preferences are seldom set. 💀

💌 Exchanging patches by e-mail 💌

`darcs send [repository]`

Send is the one that preps a bundle of patches you can apply to a target repository. It takes the URL of the repository as an argument. Call it with no argument and send uses the most recent repository that was either pushed to, pulled from, or sent to — it literally remembers, so helpful. 💅

By default the patch bundle gets saved to a file, but you can also straight-up send it by mail.

The --output, --output-auto-name, and --to flags decide what happens to the bundle after it's created:

Give it an --output argument and the bundle gets saved to that file.
Say --output-auto-name and the bundle gets saved to a file with an automatically generated name. ✨
Give one or more --to arguments and the bundle gets sent to those locations. Those locations can be email addresses, or urls that the patch should be submitted to via HTTP.

Use the --mail flag and darcs peeks inside _darcs/prefs/email in the target repository (if it exists) and emails the patch to that address. In this case you can use --cc to add extra recipients without overriding the default repository email address. 🫶

If _darcs/prefs/post exists in the target repository, darcs uploads to the URL in that file — which can be either a mailto: URL or an http:// URL. In the latter case, the patch gets posted to that URL.

And if there's no email address associated with the repository at all? Darcs just prompts you for one. 😌

Use --subject to set the subject of the e-mail being sent. Don't provide one on the command line and darcs makes one up based on the names of the patches in the bundle. Iconic behaviour honestly.

Use --in-reply-to to set the In-Reply-To and References headers of the e-mail being sent. By default no additional headers are included, so e-mail won't be treated as a reply by mail readers.

Want to include a description or explanation alongside the bundle of patches? You need --edit-description, which makes darcs open up an editor so you can compose a message to go with your patches. 📝

Want a command that isn't the default one for sending email? Specify a command line with --sendmail-command. That command line can contain format specifiers which get swapped out for the actual values. The accepted format specifiers are:

%s for subject
%t for to
%c for cc
%b for the body of the mail
%f for from
%a for the patch bundle

…and the same specifiers in uppercase for the URL-encoded values. On top of that you can add %< to the end of the command line if the command expects the complete email message on standard input.

E.g. the command lines for evolution and msmtp look like this:

evolution "mailto:%T?subject=%S&attach=%A&cc=%C&body=%B"
msmtp -t %<

Do not confuse the --author options with the return address that darcs send will set for your patch bundle.

For example, say you have two email addresses A and B:

If you use --author A but your machine is configured to send mail from address B by default, then the return address on your message will be B.
If you use --from A and your mail client supports setting the From: address arbitrarily (some non-Unix-like mail clients especially may not support this), then the return address will be A; if it does not support this, then the return address will be B.
If you supply neither --from nor --author then the return address will be B.

In addition, unless you specify the sendmail command with --sendmail-command, darcs sends email using the default email command on your computer. That default command is determined by the configure script. Which means on some non-Unix-like OSes, --from is likely to not work at all. 😭

The --inherit-default option is meant to support a work flow where you have different branches of the same upstream repository and want all your branches to have the same upstream repo as the defaultrepo. It's most useful when enabled globally by adding 'ALL --inherit-default' to your ~/darcs/defaults file.

For the commands push, pull, and send it means the following: it changes the meaning of the --set-default option so that it sets the (local) defaultrepo to the defaultrepo of the remote repo, instead of the remote repo itself. This only happens if the remote repo does have a defaultrepo set and both local and remote repositories are locally valid paths on the same host — otherwise it falls back to the default behavior (--no-inherit-default). 🦋

`darcs apply <patchfile>`

The darcs apply command takes a patch bundle and attempts to insert it into the current repository. Besides running it directly on bundles created by darcs send, it's used internally by darcs push on the remote end of an SSH connection. 🤝

No file supplied? The bundle is read from standard input.

Give it an email instead of a patch bundle and Darcs looks for the bundle as a MIME attachment to that email. Currently this will fail if the MIME boundary is rewritten, such as in Courier and Mail.app. 💀

If gpg(1) is installed, you can use --verify pubring.gpg to reject bundles that aren't signed by a key in pubring.gpg.

If --test is supplied and a test is defined (see darcs setpref), the bundle gets rejected if the test fails after applying it.

Unlike most Darcs commands, darcs apply defaults to --all. Use the --interactive option to pick which patches to apply from a bundle. 👑

A patch bundle may introduce unresolved conflicts with existing patches or with the working tree. By default, Darcs will refuse to apply conflicting patches (--no-allow-conflicts).

The --mark-conflicts option tells Darcs to allow conflicts and try to add conflict markup in your working tree. Heads up: this may (partly) fail, because some conflicts cannot be marked — like, say, conflicts between two adds of the same file. In that case Darcs warns you and displays the conflicting changes instead. And when Darcs detects conflicts with unrecorded changes, it gives you an extra warning and prompts you to confirm that you want to continue. That's because your original unrecorded changes cannot be automatically restored by Darcs. 😬

Note that conflict markup is something Darcs adds to your working tree files. Nevertheless, you can always re-construct it using darcs mark-conflicts.

The --external-merge option lets you resolve conflicts using an external merge tool. In the option, %a is replaced with the common ancestor (merge base), %1 with the first version, %2 with the second version, and %o with the path where your resolved content should go. For example, to use the xxdiff visual merge tool you'd specify: --external-merge='xxdiff -m -O -M %o %1 %a %2' 🔥

The --allow-conflicts option allows conflicts but does not add conflict markup. This is useful when you want to treat a repository as just a bunch of patches — like using darcs pull --union to download all of your co-workers' patches before going offline. Again, conflict markup can be added at any time later on using darcs mark-conflicts.

For more information on conflicts in Darcs and how to resolve them, see the help on darcs mark-conflicts. 🫶

🌈 Other commands 🌈

`darcs optimize subcommand`

The darcs optimize command modifies internal data structures of the current repository in an attempt to reduce its resource requirements. ✨

For further details see the descriptions of the subcommands.

`darcs optimize clean`

Darcs normally does not delete hashed files that are no longer referenced by the current repository state. This command can be use to get rid of these files to save some disk space. 🧹

`darcs optimize http`

Using this option creates 'repository packs' that can dramatically speed up performance when a user does a darcs clone of the repository over HTTP. To make use of packs, the clients must have a darcs of at least version 2.10. 🚀

`darcs optimize reorder`

This command moves recent patches (those not included in the latest tag) to the "front", reducing the amount that a typical remote command needs to download. It should also reduce the CPU time needed for some operations. This is the behavior with --shallow which is the default.

With the --deep option it tries to optimize all tags in the whole repository. This breaks the history of patches into smaller bunches, which can further improve efficiency, but requires all patches to be present. It is therefore less suitable for lazy clones. 🦋

`darcs optimize enable-patch-index`

Build the patch index, an internal data structure that accelerates commands that need to know what patches touch a given file. Such as annotate and log. 💅

`darcs optimize disable-patch-index`

Delete and stop maintaining the patch index from the repository.

`darcs optimize compress`

Patches, inventories, and pristine files are compressed with zlib (RFC 1951) to reduce storage (and download) size. Older darcs versions allowed to store them uncompressed, and darcs is still able to read those files if they are not compressed. 🎀

`darcs optimize uncompress` 🫧

Bestie, patches, inventories, and pristine files get squished with zlib (RFC 1951) so your repo takes up less space and downloads are less of a whole ordeal. But listen — older darcs versions were out here just... storing them raw, uncompressed, feral behaviour honestly. And modern darcs is still a sweetheart about it: it can read those files if they aren't compressed. 💖

The darcs optimize uncompress and darcs optimize compress commands can be used to ensure existing patches in the current repository are respectively uncompressed or compressed. Pick your vibe: airy and raw, or zipped and cozy. ✨

`darcs optimize relink` 🔗

This one hard-links patches that your current repository has in common with its peers. And who are the peers, you ask? They're the repositories listed in _darcs/prefs/sources, or the ones you define with the --sibling option — and yes, you can drop --sibling multiple times, it's not a one-and-done situation. 👑

Ngl though: darcs already uses hard-links automatically, so this command is rarely needed. It's giving "emergency backup plan". It's most useful if you used cp -r instead of darcs clone to copy a repository (not me doing that 😭), or if you pulled the same patch from a remote repository into multiple local repositories. Sharing is caring, and hard-links are sharing.

`darcs optimize upgrade` ⬆️

Convert old-fashioned repositories to the current default hashed format. Glow-up arc, fr fr. Your crusty old repo walks in, your sleek modern hashed-format repo walks out. 💅

`darcs optimize cache` 🧹

This command deletes obsolete files within the global cache. Spring cleaning but for your cache, and honestly? So satisfying.

It also automatically migrates the global cache to the (default) bucketed format. No action needed from you, it just does it. Iconic behaviour, no notes. 🎀

`darcs dist` 📦

darcs dist creates a compressed archive in the repository's root directory, containing the recorded state of the working tree — and heads up, unrecorded changes and the _darcs directory are excluded, so don't come for darcs when your WIP isn't in there. The command accepts matchers so you can archive some past repository state, for instance --tag. Time travel but make it a tarball. 🦋

By default, the archive (and the top-level directory within the archive) has the same name as the repository, but you can override that with the --dist-name option. Main character gets to pick her own name. ✨

If a predist command is set (see darcs setpref), that command will be run on the recorded state prior to archiving. For example, autotools projects would set it to autoconf && automake. Setup before the big reveal, we love a pre-show ritual.

⚠️ If --zip is used, matchers and the predist command are ignored. Like, fully. Don't say I didn't warn you. 💀

`darcs mark-conflicts` `[file|directory]...` 🌈

Darcs requires human guidance to reconcile independent changes to the same part of a file — it's not gonna pick a side for you, that's not the vibe. When a conflict first occurs, darcs will add the initial state and all conflicting choices to the working tree, delimited by the markers v v v, =====, * * * and ^ ^ ^, as follows:

v v v v v v v
initial state
=============
first choice
*************
...more choices...
*************
last choice
^ ^ ^ ^ ^ ^ ^

If you happened to revert or manually delete this conflict markup without actually resolving the conflict (we've all been there 🙈), darcs mark-conflicts can be used to re-create it. And similarly if you've used darcs apply or darcs pull with --allow-conflicts, where conflicts aren't marked initially. It's the "undo my undo" of conflict markup.

In Darcs, a conflict counts as resolved when all of the changes involved in the conflict (which can be more than two — it's giving group project) are depended on by one or more later patches. If you record a resolution for a particular conflict, darcs mark-conflicts will no longer mark it, indicating that it is resolved. And if you have unrecorded changes? Those count as (potential) conflict resolutions too, just as if you had already recorded them. Your working tree is out here making promises on your behalf. 😭

This principle extends to explicit "semantic" dependencies. For instance, recording a tag will automatically mark all conflicts as resolved. One tag, all drama cleared. Periodt. 👑

In the above schematic example the "initial state" corresponds to the recorded state of the file in your repository. That is to say, the recorded effect of a conflict is to apply none of the conflicting changes. And bestie, this is usually not a state you would regard as a successful resolution of the conflict — but there are exceptional situations where this may be exactly what you want. In order to tell Darcs that you want this conflict to be regarded as resolved, use darcs record --ask-deps to record a patch that explicitly depends on all patches involved in the conflict. Deliberate. Intentional. Slay.

`darcs repair` 🩹

The darcs repair command attempts to fix corruption in the current repository. It works by successively applying all patches in the repository to an empty tree, each time checking that the patch can be cleanly applied to the current pristine tree. If we detect a problem, we try to repair the patch. Finally we compare the existing pristine with the newly reconstructed one and if they differ, replace the existing one. Any problem encountered is reported — nothing gets swept under the rug here.

💅 The flag --dry-run makes this operation read-only and causes it to exit unsuccessfully (with a non-zero exit status) in case any problems are encountered. A little peek before you commit, we stan a cautious queen.

`darcs convert` subcommand 🔄

Convert repositories between various formats.

See description of the subcommands for details. (That's you, right now, reading them. Hi bestie. 🫶)

`darcs convert darcs-2` `<source>` `[<destination>]` 🧚

This command converts a repository that uses the old patch semantics darcs-1 to a new repository with current darcs-2 semantics.

WARNING: the repository produced by this command is not understood by Darcs 1.x, and patches cannot be exchanged between repositories in darcs-1 and darcs-2 formats. Also, you should not exchange patches between repositories created by different invocations of this command.

This means:

Before doing this conversion, you should merge into this repo any patches existing elsewhere that you might want to merge in future, so that they will remain mergeable. (You can always remove them again after converting).
After converting, you should tell everyone with a fork of this repo to discard it and make a new fork of the converted repo.

Communicate with your people, it's a whole ecosystem thing. 🌸

`darcs convert export` 📤

This command enables you to export darcs repositories into git. Crossing the fandom divide, respect.

For a one-time export you can use the recipe:

$ cd repo
$ git init ../mirror
$ darcs convert export | (cd ../mirror && git fast-import)

For incremental export using marksfiles:

$ cd repo
$ git init ../mirror
$ touch ../mirror/git.marks
$ darcs convert export --read-marks darcs.marks --write-marks darcs.marks | (cd ../mirror && git fast-import --import-marks=git.marks --export-marks=git.marks)

⚠️ In the case of incremental export, be careful to never amend, delete or reorder patches in the source darcs repository. Do not. Touch. The history. It's giving forbidden snack.

Also, be aware that exporting a darcs repo to git will not be exactly faithful in terms of history if the darcs repository contains conflicts. Some lore gets lost in translation, iykyk. 😭

Limitations:

Empty directories are not supported by the fast-export protocol.
Unicode filenames are currently not correctly handled. See http://bugs.darcs.net/issue2359 .

`darcs convert import` `[<directory>]` 📥

This command imports git repositories into new darcs repositories. Further options are accepted (see darcs help init).

To convert a git repo to a new darcs one you may run:

$ (cd gitrepo && git fast-export --all -M) | darcs convert import darcsmirror

WARNING: git repositories with branches will produce weird results, use at your own risks. Weird as in chaos, not weird as in cute. 💀

Incremental import with marksfiles is currently not supported. One shot only, bestie.

`darcs fetch` `[repository]...` 🍓

Fetch is similar to pull except that it does not apply any patches to the current repository. Instead, it generates a patch bundle that you can apply later with apply. It's the "add to cart" of darcs. 🛒✨

Fetch's behaviour is essentially similar to pull's, so please consult the help of pull to know more.

🌸 ENVIRONMENT 🌸

okay bestie, this is the part where darcs peeks at your environment variables to figure out how you like to live 💅. every single knob is below, no skips, periodt.

🏠 HOME and APPDATA

Your per-user preferences live in $HOME/.darcs if you're on Unix, or %APPDATA%/darcs if you're on Windows 🪟. That same spot is also the default home of the cache. so like, one folder, two jobs, very main character energy.

✏️ DARCS_EDITOR, VISUAL, and EDITOR

When darcs needs to edit a patch description or an email comment, it calls in an external editor 🎀. You can set your fave via any of $DARCS_EDITOR, $VISUAL, or $EDITOR. If none of those are set, nano is the default pick. But if nano crashes or isn't found in your PATH, darcs tries vi, emacs, emacs -nw and (on Windows) edit, each one in turn. so it will find someone, ngl.

If some command's output is longer than 20 lines, darcs brings out a pager 📖. It'll use whatever $DARCS_PAGER or $PAGER says. If neither is set, less gets the job. Wanna yeet the pager entirely? Set $DARCS_PAGER — or $PAGER if the first one isn't set — to the empty string. poof, no pager ✨.

🌈 DARCS_DONT_COLOR, DARCS_ALWAYS_COLOR, and DARCS_ALTERNATIVE_COLOR

If your terminal gets ANSI color escape sequences, darcs will highlight certain keywords and delimiters when printing patches, and also print hunk lines in color depending on whether they're removed or added 🔥. Turn the whole thing off by setting DARCS_DONT_COLOR to 1. If you're using a pager that happens to understand ANSI colors — like less -R — you can force darcs to always highlight output by setting DARCS_ALWAYS_COLOR to 1. And if colors just aren't visible to you, set DARCS_ALTERNATIVE_COLOR to 1 and darcs will use ANSI codes for bold and reverse video instead of colors 🫶.

🫧 DARCS_DONT_ESCAPE_TRAILING_SPACES and DARCS_DONT_ESCAPE_TRAILING_CR

By default, when showing patch contents, darcs escapes any kind of spaces at the end of lines (by highlighting them if possible) 👀. Not feeling it? Set DARCS_DONT_ESCAPE_TRAILING_SPACES to 1 and it stops. There's a special-case variable for carriage returns only: DARCS_DONT_ESCAPE_TRAILING_CR.

🧚 DARCS_DONT_ESCAPE_ANYTHING, DARCS_DONT_ESCAPE_EXTRA, DARCS_ESCAPE_EXTRA, DARCS_DONT_ESCAPE_ISPRINT, and DARCS_ESCAPE_8BIT

Darcs has to escape certain characters when it prints patch contents to a terminal, and which ones depends on the encoding in your locale setting 🦋.

By default, darcs assumes your locale encoding is ASCII compatible 💜. That includes UTF-8 and some 8-bit encodings like ISO/IEC-8859 (variants included). ASCII contains control characters like backspace — which could hide patch content from you when printed literally to the terminal 😭 — and even ones that may introduce security risks, like redirecting commands to the shell 💀. So darcs escapes those. They get printed as ^<control letter> or <hex code>. Darcs also uses special markup for line endings that are preceded by white space, since that white space would otherwise be unrecognizable.

If your encoding is not ASCII compatible, things get a lil less smooth 🥲. Such encodings include UTF-16 and UTF-32, plus many of the encodings that became obsolete with unicode. You've got two options here:

Set DARCS_DONT_ESCAPE_ANYTHING to 1. Then everything that doesn't flip code sets should work, and so will all the bells and whistles in your terminal ✨. This one's also handy if you pipe output to a pager or external filter that knows better than darcs how to handle your encoding. Heads up though: all escaping gets turned off by this setting, including the special escaping of any line ending spaces.
Tell darcs explicitly to not escape or to escape certain bytes, using DARCS_DONT_ESCAPE_EXTRA and DARCS_ESCAPE_EXTRA 💅. Their values should be strings made of the verbatim bytes in question. The do-escapes take precedence over the dont-escapes. Space characters are still escaped at line endings though. And the special env var DARCS_DONT_ESCAPE_TRAILING_CR turns off escaping of carriage return last on the line (DOS style).

For historical reasons, darcs also supports DARCS_DONT_ESCAPE_ISPRINT and DARCS_USE_ISPRINT (they're synonyms). These make sense only for 8-bit encodings like ISO-8859 and are no longer needed, since nowadays darcs does the right thing here by default 🎀.

Finally, if you're in a highly security sensitive situation (or just paranoid for other reasons 🙈), you can set DARCS_ESCAPE_8BIT to 1. This makes darcs escape every non-ASCII byte in addition to ASCII control characters. locked down, no cap.

🗂️ DARCS_TMPDIR and TMPDIR

Darcs makes temporary directories all the time, bestie. For example, the darcs diff command creates two of them for the working trees to be diffed. By default these temp dirs get made in /tmp, or if that doesn't exist, in _darcs (inside the current repo). You can override this by naming another directory in the file _darcs/prefs/tmpdir or via the environment variable $DARCS_TMPDIR or $TMPDIR 📁.

🛑 DARCS_KEEP_TMPDIR

If the environment variable DARCS_KEEP_TMPDIR is defined, darcs will not remove the temporary directories it creates 🚫🗑️. This is intended primarily for debugging Darcs itself, but it can also be useful — for example, to figure out why your test preference (see darcs setpref) is failing when you run darcs record, but working when run manually. detective mode 🔍.

📧 DARCS_EMAIL and EMAIL

Every patch is attributed to its author, usually by email address (for example, Fred Bloggs <fred@example.net>) 👑. Darcs looks in several places for this author string:

the --author option
the files _darcs/prefs/author (in the repository) and ~/.darcs/author (in your home directory)
the environment variables $DARCS_EMAIL and $EMAIL

If none of those exist, darcs will prompt you for an author string and write it to ~/.darcs/author ✍️. Also, if you have more than one email address, you can put them all in ~/.darcs/author, one author per line. Darcs will still prompt you for an author, but it lets you select from the list, or type in an alternative. choose your fighter 💖.

📮 SENDMAIL

On Unix, the darcs send command relies on sendmail(8) 📨. The --sendmail-command or $SENDMAIL environment variable can give an explicit path to this program; otherwise the standard locations /usr/sbin/sendmail and /usr/lib/sendmail will be tried.

🔒 DARCS_SLOPPY_LOCKS

If on some filesystems you get an error of the kind:

darcs: takeLock [...]: atomic_create [...]: unsupported operation

you may want to try to export DARCS_SLOPPY_LOCKS=True 😮‍💨.

🔌 DARCS_SSH

Repositories of the form [user@]host:[dir] are taken to be remote repositories, which darcs accesses with the external program ssh(1) 🛰️.

The environment variable $DARCS_SSH can be used to specify an alternative SSH client. Arguments may be included, separated by whitespace. But important: the value is not interpreted by a shell, so shell constructs cannot be used — in particular, it is not possible for the program name to contain whitespace by using quoting or escaping ⚠️.

📡 DARCS_SCP and DARCS_SFTP

When reading from a remote repository, darcs will attempt to run darcs transfer-mode on the remote host 🌍. This will fail if the remote host only has Darcs 1 installed, doesn't have Darcs installed at all, or only allows SFTP 😬.

If transfer-mode fails, darcs falls back on scp(1) and sftp(1) 🫡. The commands invoked can be customized with the environment variables $DARCS_SCP and $DARCS_SFTP respectively, which behave like $DARCS_SSH. If the remote end allows only sftp, try setting DARCS_SCP=sftp.

scp is also used by darcs clone if the destination is a remote ssh directory. That operation can be made quite a bit faster by setting DARCS_SCP=rsync 🏎️.

🚪 SSH_PORT

If this environment variable is set, it'll be used as the port number for all SSH calls darcs makes (when accessing remote repositories over SSH) 🔑. This is useful if your SSH server doesn't run on the default port, and your SSH client doesn't support ssh_config(5). OpenSSH users will probably prefer to put something like Host *.example.net Port 443 into their ~/.ssh/config file instead.

⏱️ DARCS_CONNECTION_TIMEOUT

Set the maximum time in seconds that darcs allows a connection to take ⏳. If the variable isn't specified, the default is 30 seconds. Heads up: this option only works with curl.

✨ FILES ✨

Okay bestie, this is where Darcs keeps all its little configuration treasures. Buckle up, because each file has a whole personality. 💖

🎀 `_darcs/prefs/motd`

The _darcs/prefs/motd file may contain a 'message of the day' which will be displayed to users who clone or pull from the repository without the --quiet option. It's literally the repo's away message. 💅

💌 `_darcs/prefs/email`

The _darcs/prefs/email file is used to provide the e-mail address for your repository that others will use when they darcs send a patch back to you. The contents of the file should simply be an e-mail address. No fancy formatting, just the address, periodt. 📧

📮 `_darcs/prefs/post`

If _darcs/prefs/post exists in the target repository, darcs send will upload to the URL contained in that file, which may either be a mailto: URL, or an http:// URL. In the latter case, the patch is posted to that URL. So it's giving either "email it" or "HTTP POST it" energy. 🦋

👑 `_darcs/prefs/author`

The _darcs/prefs/author file contains the email address (or name) to be used as the author when patches are recorded in this repository, e.g. David Roundy <droundy@abridgegame.org>. This file overrides the contents of the environment variables $DARCS_EMAIL and $EMAIL. So if you want your commits to have main character energy, this is the file. ✨

⚙️ `_darcs/prefs/defaults`

Default options for darcs commands. Each line of this file has the following form:

COMMAND FLAG VALUE

where COMMAND is either the name of the command to which the default applies, or ALL to indicate that the default applies to all commands accepting that flag. The FLAG term is the name of the long argument option with or without the --, i.e. verbose or --verbose. Finally, the VALUE option can be omitted if the flag does not involve a value. If the value has spaces in it, use single quotes, not double quotes, to surround it. Each line only takes one flag. To set multiple defaults for the same command (or for ALL commands), use multiple lines.

Options listed in the defaults file are just that: defaults. You can override any default on the command line. No cap. 🙌

Note that the use of ALL easily can have unpredicted consequences, especially if commands in newer versions of darcs accepts flags that they did not in previous versions. Only use safe flags with ALL.

For example, if your system clock is bizarre, you could instruct darcs to always ignore the file modification times by adding the following line:

ALL ignore-times

There are some options which are meant specifically for use in _darcs/prefs/defaults. One of them is --disable. As the name suggests, this option will disable every command that got it as argument. So, if you are afraid that you could damage your repositories by inadvertent use of a command like amend, add the following line:

amend disable

A global defaults file can be created with the name .darcs/defaults in your home directory. In case of conflicts, the defaults for a specific repository take precedence. So the repo-level file is the louder bestie. 💅

🧚 `_darcs/prefs/boring`

The _darcs/prefs/boring file may contain a list of regular expressions describing files, such as object files, that you do not expect to add to your project. A newly created repository has a boring file that includes many common source control, backup, temporary, and compiled files.

You may want to have the boring file under version control. To do this you can use darcs setpref to set the value 'boringfile' to the name of your desired boring file (e.g. darcs setpref boringfile .boring, where .boring is the repository path of a file that has been darcs added to your repository). The boringfile preference overrides _darcs/prefs/boring, so be sure to copy that file to the boringfile.

You can also set up a 'boring' regexps file in your home directory, named ~/.darcs/boring, which will be used with all of your darcs repositories. Global boredom, iconic. 🌈

Any file not already managed by darcs and whose repository path matches any of the boring regular expressions is considered boring. The boring file is used to filter the files provided to darcs add, to allow you to use a simple darcs add newdir newdir/* without accidentally adding a bunch of object files. It is also used when the --look-for-adds flag is given to whatsnew or record. Note that once a file has been added to darcs, it is not considered boring, even if it matches the boring file filter. So once you commit, you're no longer boring, you're canon. 🎀

🔥 `_darcs/prefs/binaries`

The _darcs/prefs/binaries file may contain a list of regular expressions describing files that should be treated as binary files rather than text files. Darcs automatically treats files containing characters ^Z or NULL within the first 4096 bytes as being binary files. You probably will want to have the binaries file under version control. To do this you can use darcs setpref to set the value 'binariesfile' to the name of your desired binaries file (e.g. darcs setpref binariesfile ./.binaries, where .binaries is a file that has been darcs added to your repository). As with the boring file, you can also set up a ~/.darcs/binaries file if you like. Binary files stay winning. 💀✨

🌸 `_darcs/prefs/defaultrepo`

Contains the URL of the default remote repository used by commands pull, push, send and optimize relink. Darcs edits this file automatically or when the flag --set-default is used. It's the repo's "home base" vibe. 🏠

🦋 `_darcs/prefs/sources`

Besides the defaultrepo, darcs also keeps track of any other locations used in commands for exchanging patches (e.g. push, pull, send). These are subsequently used as alternatives from which to download patches. The file contains lines such as:

cache:/home/droundy/.cache/darcs
readonly:/home/otheruser/.cache/darcs
repo:http://darcs.net

The prefix cache: indicates that darcs can use this as a read-write cache for patches, read-only: indicates a cache that is only readable, and repo: denotes a (possibly remote) repository. The order of the entries is immaterial: darcs will always try local paths before remote ones, and only local ones will be used as potentially writable.

A global cache is enabled by default in your home directory under .cache/darcs (older versions of darcs used .darcs/cache for this), or $XDG_CACHE_HOME/darcs if the environment variable is set, see https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html. The cache allows darcs to avoid re-downloading patches (for example, when doing a second darcs clone of the same repository), and also allows darcs to use hard links to reduce disk usage. It's giving "we already have that patch at home". 🏡

Note that the cache directory should reside on the same filesystem as your repositories, so you may need to vary this. You can also use multiple cache directories on different filesystems, if you have several filesystems on which you use darcs.

While darcs automatically adds entries to _darcs/prefs/sources, it does not currently remove them. If one or more of the entries aren't accessible (e.g. because they resided on a removable media), then darcs will bugger you with a hint, suggesting you remove those entries. This is done because certain systems have extremely long timeouts associated with some remotely accessible media (e.g. NFS over automounter on Linux), which can slow down darcs operations considerably. On the other hand, when you clone a repo with --lazy from a no longer accessible location, then the hint may give you an idea where the patches could be found, so you can try to restore access to them. So the hint is annoying but also lowkey a detective. 🕵️‍♀️

🍓 `_darcs/prefs/tmpdir`

By default temporary directories are created in /tmp, or if that doesn't exist, in _darcs (within the current repo). This can be overridden by specifying some other directory in the file _darcs/prefs/tmpdir or the environment variable $DARCS_TMPDIR or $TMPDIR. Choose your temp home wisely. 🏕️

💜 `_darcs/prefs/prefs`

Contains the preferences set by the command darcs setprefs. Do not edit manually. Just don't. Hands off. 🙈

🐛 BUGS

At http://bugs.darcs.net/ you can find a list of known bugs in Darcs. Unknown bugs can be reported at that site (after creating an account) or by emailing the report to bugs@darcs.net. If you find a bug, you're not being dramatic, you're being a good citizen. 💖

👀 SEE ALSO

The Darcs website provides a lot of additional information. It can be found at http://darcs.net/. Go forth and read, bestie. 📚✨

📜 LICENSE

Darcs is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. Slay, but legally. 💅

And that's the whole page, bestie! This is DARCS(1) from Darcs 2.18.5 (release) — that's the source/version on the footer, and there's no date line, so we're just gonna vibe. Stay iconic, keep your repos clean, and remember: defaults are just defaults. Periodt. 🎀✨💖

📦 where this page comes from

alpine 3.24: darcs-doc 2.18.5-r1 · GPL-2.0-or-later
arch rolling: darcs 2.18.5-317 · GPL-2.0-or-later
fedora 43: darcs 2.18.5-48.fc43 · GPL-2.0-or-later
fedora 44: darcs 2.18.5-51.fc44 · GPL-2.0-or-later
nixos 26.05: darcs 2.18.5
nixpkgs unstable: darcs 2.18.5
ubuntu resolute: darcs 2.18.5-1 · GPL-2.0-or-later
ubuntu stonking: darcs 2.18.5-2 · GPL-2.0-or-later
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-13: a language model's rewrite of the original, under its terms

DARCS(1)

DARCS(1) — General Commands Manual

💖 NAME 💖

🌈 SYNOPSIS 🌈

💫 DESCRIPTION 💫

✨ OPTIONS ✨

💅 Selecting Patches 💅

👑 COMMANDS 👑

🫶 darcs help [<darcs_command> [darcs_subcommand]]

🌸 Most used/starting out: 🌸

🎀 darcs initialize [<directory>]

🦋 darcs add <file|directory> ...

🍓 darcs whatsnew [file|directory]...

🧚 darcs record [file|directory]...

🌈 darcs clone <repository> [<directory>] 🌈

💜 darcs pull [repository]... 💜

🎀 darcs push [repository] 🎀

🌸 Preparing patches before recording 🌸

🔍 Querying the repository 🔍

🌸 darcs show index

🦋 darcs show pristine

👑 darcs show repo

💜 darcs show authors

🎀 darcs show tags

⭐ darcs show patch-index

💅 Undoing and correcting:

🧚 darcs revert [file|directory]...

🌈 darcs unrevert

✨ darcs amend [file|directory]...

🦋 darcs rebase subcommand

darcs rebase pull [repository]...

darcs rebase apply <patchfile>

darcs rebase suspend

darcs rebase unsuspend

darcs rebase edit

darcs rebase obliterate

darcs rebase log

darcs rebase upgrade

darcs rollback [file|directory]...

darcs unrecord

darcs obliterate

darcs clean [file|directory]...

🌈 Direct modification of the repository:

darcs tag [tagname]

darcs setpref <pref> <value>

💌 Exchanging patches by e-mail 💌

darcs send [repository]

darcs apply <patchfile>

🌈 Other commands 🌈

darcs optimize subcommand

darcs optimize clean

darcs optimize http

darcs optimize reorder

darcs optimize enable-patch-index

darcs optimize disable-patch-index

darcs optimize compress

darcs optimize uncompress</p> 🫧

darcs optimize relink</p> 🔗

darcs optimize upgrade</p> ⬆️

darcs optimize cache</p> 🧹

darcs dist</p> 📦

darcs mark-conflicts</p> [file|directory]... 🌈

darcs repair</p> 🩹

darcs convert</p> subcommand 🔄

darcs convert darcs-2</p> <source> [<destination>] 🧚

darcs convert export</p> 📤

darcs convert import</p> [<directory>] 📥

darcs fetch</p> [repository]... 🍓

🌸 ENVIRONMENT 🌸

🏠 HOME and APPDATA

✏️ DARCS_EDITOR, VISUAL, and EDITOR

📜 DARCS_PAGER and PAGER

🌈 DARCS_DONT_COLOR, DARCS_ALWAYS_COLOR, and DARCS_ALTERNATIVE_COLOR

🫧 DARCS_DONT_ESCAPE_TRAILING_SPACES and DARCS_DONT_ESCAPE_TRAILING_CR

🧚 DARCS_DONT_ESCAPE_ANYTHING, DARCS_DONT_ESCAPE_EXTRA, DARCS_ESCAPE_EXTRA, DARCS_DONT_ESCAPE_ISPRINT, and DARCS_ESCAPE_8BIT

🗂️ DARCS_TMPDIR and TMPDIR

🛑 DARCS_KEEP_TMPDIR

📧 DARCS_EMAIL and EMAIL

📮 SENDMAIL

🔒 DARCS_SLOPPY_LOCKS

🫶 `darcs help [<darcs_command> [darcs_subcommand]]`

🎀 `darcs initialize [<directory>]`

🦋 `darcs add <file|directory> ...`

🍓 `darcs whatsnew [file|directory]...`

🧚 `darcs record [file|directory]...`

🌈 `darcs clone <repository> [<directory>]` 🌈

💜 `darcs pull [repository]...` 💜

🎀 `darcs push [repository]` 🎀

🌸 `darcs show index`

🦋 `darcs show pristine`

👑 `darcs show repo`

💜 `darcs show authors`

🎀 `darcs show tags`

⭐ `darcs show patch-index`

🧚 `darcs revert [file|directory]...`

🌈 `darcs unrevert`

✨ `darcs amend [file|directory]...`

🦋 `darcs rebase subcommand`

`darcs rebase pull [repository]...`

`darcs rebase apply <patchfile>`

`darcs rebase suspend`

`darcs rebase unsuspend`

`darcs rebase edit`

`darcs rebase obliterate`

`darcs rebase log`

`darcs rebase upgrade`

`darcs rollback [file|directory]...`

`darcs unrecord`

`darcs obliterate`

`darcs clean [file|directory]...`

`darcs tag [tagname]`

`darcs setpref <pref> <value>`

`darcs send [repository]`

`darcs apply <patchfile>`

`darcs optimize subcommand`

`darcs optimize clean`

`darcs optimize http`

`darcs optimize reorder`

`darcs optimize enable-patch-index`

`darcs optimize disable-patch-index`

`darcs optimize compress`

`darcs optimize uncompress`</p> 🫧

`darcs optimize relink`</p> 🔗

`darcs optimize upgrade`</p> ⬆️

`darcs optimize cache`</p> 🧹

`darcs dist`</p> 📦

`darcs mark-conflicts`</p> `[file|directory]...` 🌈

`darcs repair`</p> 🩹

`darcs convert`</p> subcommand 🔄

`darcs convert darcs-2`</p> `<source>` `[<destination>]` 🧚

`darcs convert export`</p> 📤

`darcs convert import`</p> `[<directory>]` 📥

`darcs fetch`</p> `[repository]...` 🍓

🎀 `_darcs/prefs/motd`

💌 `_darcs/prefs/email`

📮 `_darcs/prefs/post`

👑 `_darcs/prefs/author`

⚙️ `_darcs/prefs/defaults`

🧚 `_darcs/prefs/boring`

🔥 `_darcs/prefs/binaries`

🌸 `_darcs/prefs/defaultrepo`

🦋 `_darcs/prefs/sources`

🍓 `_darcs/prefs/tmpdir`

💜 `_darcs/prefs/prefs`