The mapped drive is not a git working copy

What you'll see

Someone — often an AI coding agent on its first pass — opens a mapped Docly drive, finds no .git directory, and runs git init to get version control before starting work. Or the opposite: they are told "Docly has no git", accept it, and spend the project editing production directly with no history at all.

Both are wrong, in opposite directions.

What's actually happening

The mapped drive is a WebDAV mount of the live application. There is no working copy there because the files are the running site. Running git init against it does not give you version control of your deployment — it creates a .git directory inside the application, on a filesystem where every object read and write is an HTTP round trip. The result is a repository that is slow to the point of unusable, sitting in a folder your non-developer users can see, tracking a tree that changes underneath it whenever anyone edits through the Docly UI.

But Docly does speak git. Every folder is exposed as a git repository at https://<instance>/git/<Folder>. Authentication goes through a small credential helper rather than a password: git always sends credentials as HTTP Basic, and Docly does not accept an account password there, so git-credential-docly opens your browser, you sign in normally — including two-factor — and it hands git a short-lived token. Access follows the same rules as the rest of Docly; you clone only what you can already see.

Once cloned you have an ordinary local repository. Branch, rebase, commit as often as you like; nothing reaches the live site until you push. That is a genuinely different workflow from the mapped drive, and for anything with a review step it is the better one.

What to do

On a mapped drive: never git init. If you want history there, copy files out before editing — see Work safely on a live site.

To use git properly, clone instead. Full instructions, including the download links for each platform, are in Using Git with Docly. In short:

# 1. Put git-credential-docly on your PATH (name must be exact)

# 2. Once per Docly instance - note: NO trailing slash
git config --global credential.https://docly.net.helper docly

# 3. Clone
git clone https://docly.net/git/Projects

# 4. Work normally
git add .
git commit -m "Updated the report"
git push

A trailing slash in step 2 silently fails to match, and git falls back to asking for a password — which does not work. If the helper is not found, check the filename: git locates it by looking for a program called exactly git-credential-docly.

There is also a third route: the docly CLI

The choice is no longer just «drive or git». docly is a command line client that clones a folder into a local working copy, shows you a line-level diff, and pushes when you say so — the reviewable part of the git workflow, without a git server, a credential helper or a second copy of your authentication. It also refuses to write anything until someone has explicitly opened one folder for writing, which is a bound on blast radius neither of the other two routes has.

For anything scripted or agent-driven it is normally the right answer. See How an AI agent should use the docly CLI.

Choosing between the three

Whichever you pick, state it explicitly in the workspace's agent instruction file so an agent does not have to guess — see Set up AI agent instruction files for a workspace.