Getting the code

DunneFlow never asks a version control system anything. It has no git, Perforce or other client, no credentials and no remotes. What it reads is a directory of files on your disk. How that directory got there is your business.

That is deliberate. A tree on a memory stick, a nightly build on a share, a vendor's release tarball and a git clone are all the same problem, and a tool that only understood one of them would be useless in the case where you need it most: code you have been given and cannot ask questions about.

So there are two separate steps. Get a directory. Point DunneFlow at it.

Git#

git clone https://github.com/some-org/some-project ~/code/some-project

Two things to check before you analyse it.

Are you on the branch the work is actually on? Cloning gets you the default branch, which on some projects is well behind where people are working. A map of a stale branch analyses perfectly and describes a program nobody is running.

git clone -b the-branch-they-use https://github.com/some-org/some-project ~/code/some-project

Is the whole tree there? A shallow clone (--depth 1) is fine, because DunneFlow reads only the working tree, never the history. A sparse checkout is not: files that are not on disk are files DunneFlow cannot see, and it will confidently map a smaller program.

A second version to compare against#

Comparing two versions needs two directories. With git, the cheapest way to get a second one is a worktree:

git worktree add ~/code/some-project-2026-09-08 <commit-or-tag>

That gives you a second complete tree that shares one object store. Name it for what it is, with a date, tag or release, because DunneFlow records the name of the directory it read and that is how you will tell the two versions apart later.

Perforce#

Sync a workspace to local disk, then point DunneFlow at the workspace root:

p4 client -o some-project-ws | p4 client -i
p4 sync //depot/some-project/...@2026-09-08

For a second version, sync a second workspace at a different changelist or label, and name its directory for that changelist or release. Perforce workspaces are often partial by design, through the client view; as with a sparse checkout, what is not on disk is not in the map.

No version control at all#

A zip, a tarball, a folder someone sent you, a vendor drop: unpack it and point DunneFlow at it. This is the case DunneFlow is best at. There is no history, no blame and no commit messages, only the code, which is all DunneFlow ever reads.

What DunneFlow records about where the code came from#

A map is built to be handed over: copied to a colleague, kept after the source has moved on, and opened on a machine that has never held the code. So what it records about its origin is short and deliberate.

• Not recorded: the path to the tree. Every stored path is relative, and the root is never written down. A path is one machine's layout, it goes stale the moment anything moves, and it can leak directory names you did not mean to share.
• The one exception: a standards directory given with --standards is recorded by its full path in standards.db, because a quoted rule is worth little without saying which document it came from.
• Recorded: the leaf of the directory, such as some-project-2026-09-08. That is the project's directory, not necessarily the one you pointed at: analyse ~/code/some-project/src and the map says some-project, because src identifies nothing.
• Recorded: the version the program states about itself, from pyproject.toml or a module-level __version__, with the file that proves it. If the source says nothing, a version may be guessed from the directory name (such as app-1.2.3) and is marked as a guess wherever it appears.

This is why the directory name matters. It is the only handle you get.

Next: The start page and your first map.